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You know you don’t want to reinvent the wheel (or worse, a flat tire), so 
you look to design patterns—the lessons learned by those who've faced 
the same software design problems. With design patterns, you get to take 
advantage of the best practices and experience of others, so that you 

can spend your time on...something else. Something more challenging. 


Something more complex. Something more fun. You want to learn: 
e The patterns that matter 

e When to use them, and why 

e How to apply them to your own designs, right now 

e When not to use them (how to avoid pattern fever) 

e OO design principles on which patterns are based 


Most importantly, you want to learn design patterns in a way that won’t put 
you to sleep. If you've read a Head First book, you know what to expect— 
a visually rich format designed for the way your brain works. Using the latest 
research in neurobiology, cognitive science, and learning theory, Head 
First Design Patterns will load patterns into your brain in a way that sticks. 
In a way that makes you better at solving software design problems, and 
better at speaking the language of patterns with others on your team, 


Eric Freeman and Elisabeth Freeman are authors, educators, and tech- 
nology innovators. After four years leading digital media and Internet 
efforts at the Walt Disney Company, they’re applying some of that 

pixie dust to their own media, including this book. Eric and Elisabeth 


both hold computer science degrees from Yale 


University: Elisabeth holds an M.S. degree and 
Eric a Ph.D. 


Kathy Sierra (founder of javaranch.com) and 
Bert Bates are the creators of the best-selling 

Head First series and developers of Sun 
Microsystems Java developer certification 


exams. 
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Praise for Head First Design Patterns 


“T received the book yesterday and started to read it on the way home... and I couldn’t stop. I took it to the 
gym and I expect people saw me smiling a lot while I was exercising and reading. This is tres ‘cool’. It is 
fun but they cover a lot of ground and they are right to the point. I’m really impressed.” 

— Erich Gamma, IBM Distinguished Engineer, 
and co-author of Design Patterns 


““Head First Design Patterns’ manages to mix fun, belly-laughs, insight, technical depth and great practical 
advice in one entertaining and thought provoking read. Whether you are new to design patterns, or have 
been using them for years, you are sure to get something from visiting Objectville.” 


— Richard Helm, coauthor of “Design Patterns” with rest of the 
Gang of Four - Erich Gamma, Ralph Johnson and John Vlissides 


“T feel like a thousand pounds of books have just been lifted off of my head.” 


— Ward Cunningham, inventor of the Wiki 
and founder of the Hillside Group 


“This book is close to perfect, because of the way it combines expertise and readability. It speaks with 
authority and it reads beautifully. It’s one of the very few software books [I’ve ever read that strikes me as 
indispensable. (?'d put maybe 10 books in this category, at the outside.)” 


— David Gelernter, Professor of Computer Science, 
Yale University and author of “Mirror Worlds” and “Machine Beauty” 


“A Nose Dive into the realm of patterns, a land where complex things become simple, but where simple 
things can also become complex. I can think of no better tour guides than the Freemans.” 


— Miko Matsumura, Industry Analyst, The Middleware Company 
Former Chief Java Evangelist, Sun Microsystems 


“T laughed, I cried, it moved me.” 


— Daniel Steinberg, Editor-in-Chief, java.net 


“My first reaction was to roll on the floor laughing. After I picked myself up, I realized that not only is the 
book technically accurate, it is the easiest to understand introduction to design patterns that I have seen.” 


— Dr. Timothy A. Budd, Associate Professor of Computer Science at 
Oregon State University and author of more than a dozen books, 
including “C++ for Java Programmers” 


“Jerry Rice runs patterns better than any receiver in the NFL, but the Freemans have out run him. 
Seriously...this is one of the funniest and smartest books on software design I’ve ever read.” 


— Aaron LaBerge, VP Technology, ESPN.com 


More Praise for Head First Design Patterns 


“Great code design is, first and foremost, great information design. A code designer is teaching a com- 
puter how to do something, and it is no surprise that a great teacher of computers should turn out to be 
a great teacher of programmers. This book’s admirable clarity, humor and substantial doses of clever 
make it the sort of book that helps even non-programmers think well about problem-solving.” 


— Cory Doctorow, co-editor of Boing Boing 
and author of “Down and Out in the Magic Kingdom” 
and “Someone Comes to Town, Someone Leaves Town” 


“There’s an old saying in the computer and videogame business ~ well, it can’t be that old because the 
discipline is not all that old — and it goes something like this: Design is Life. What’s particularly curious 
about this phrase is that even today almost no one who works at the craft of creating electronic games 
can agree on what it means to “design” a game. Is the designer a software engineer? An art director? 
A storyteller? An architect or a builder? A pitch person or a visionary? Can an individual indeed be in 
part all of these? And most importantly, who the %o$!#&* cares? 


It has been said that the “designed by” credit in interactive entertainment is akin to the “directed by” 
credit in filmmaking, which in fact allows it to share DNA with perhaps the single most controversial, 
overstated, and too often entirely lacking in humility credit grab ever propagated on commercial art. 
Good company, eh? Yet if Design is Life, then perhaps it is time we spent some quality cycles thinking 
about what it is. 


Eric and Elisabeth Freeman have intrepidly volunteered to look behind the code curtain for us in 
“Head First Design Patterns.” I’m not sure either of them cares all that much about the PlayStation 
or X-Box, nor should they. Yet they do address the notion of design at a significantly honest level such 
that anyone looking for ego reinforcement of his or her own brilliant auteurship is best advised not to 
go digging here where truth is stunningly revealed. Sophists and circus barkers need not apply. Next 
generation literati please come equipped with a pencil.” 


— Ken Goldstein, Executive Vice President & Managing Director, 
Disney Online 


“Just the right tone for the geeked-out, casual-cool guru coder in all of us. The right reference for 
practical development strategies—gets my brain going without having to slog through a bunch of tired, 
stale professor-speak.” 


— Travis Kalanick, Founder of Scour and Red Swoosh 
Member of the MIT TR100 


“This book combines good humors, great examples, and in-depth knowledge of Design Patterns in 
such a way that makes learning fun. Being in the entertainment technology industry, I am intrigued 
by the Hollywood Principle and the home theater Facade Pattern, to name a few. The understanding 
of Design Patterns not only helps us create reusable and maintainable quality software, but also helps 
sharpen our problem-solving skills across all problem domains. This book is a must read for all com- 
puter professionals and students.” 


— Newton Lee, Founder and Editor-in-Chief, Association for Computing 
Machinery’s (ACM) Computers in Entertainment (acmcie.org) 


Praise for the Head First approach 


“Java technology is everywhere—in mobile phones, cars, cameras, printers, games, PDAs, ATMs, smart 
cards, gas pumps, sports stadiums, medical devices, Web cams, servers, you name it. If you develop 
software and haven't learned Java, it’s definitely time to dive n—Head First.” 


— Scott McNealy, Sun Microsystems Chairman, President and CEO 


“Tt’s fast, irreverent, fun, and engaging. Be careful—you might actually learn something!” 


— Ken Arnold, former Senior Engineer at Sun Microsystems 
Co-author (with James Gosling, creator of Java), 
“The Java Programming Language” 


“Head First Java is like Monty Python meets the gang of four... the text is broken up so well by puzzles and 
stories, quizzes and examples, that you cover ground like no computer book before.” 


— Douglas Rowe, Columbia Java Users Group 


“ “Head First Java’... gives new meaning to their marketing phrase “There’s an O Reilly for that.* I picked 
this up because several others I respect had described it in terms like ‘revolutionary’ and a described a 
radically different approach to the textbook. They were (are) right... In typical O’Reilly fashion, they’ve 
taken a scientific and well considered approach. The result is funny, irreverent, topical, interactive, and 
brilhant...Reading this book is like sitting in the speakers lounge at a view conference, learning from 

~ and laughing with — peers... If you want to UNDERSTAND Java, go buy this book.” 


— Andrew Pollack, www.thenorth.com 


“Tf you want to learn Java, look no further: welcome to the first GUI-based technical book! This perfectly- 
executed, ground-breaking format delivers benefits other Java texts simply can’t... Prepare yourself for a 
truly remarkable ride through Java land.” 


— Neil R. Bauman, Captain & CEO, Geek Cruises (www.GeekCruises.com) 


What a fantastic way to learn!!! 1! GAN NOT PUT THIS BOOK DOWN!!! My 3 year old woke up at 
1:40 a.m. this morning, and I put him back to bed with book in hand and a flashlight so I could continue 
to read for about another hour. 


— Ross Goldberg 


“This stuff is so fricking good it makes me wanna WEEP! I’m stunned.” 


— Floyd Jones, Senior Technical Writer/Poolboy, BEA 
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Welcome to Design Patterns 


Someone has already solved your problems. in this chapter, 
you'll learn why (and how) you can exploit the wisdom and lessons learned by 
other developers who've been down the same design problem road and survived 
the trip. Before we’re done, we'll look at the use and benefits of design patterns, 
look at some key OO design principles, and walk through an example of how one 
pattern works. The best way to use patterns is to load your brain with them and 
then recognize places in your designs and existing applications where you can 


apply them. Instead of code reuse, with patterns you get experience reuse. 
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Keeping your Objects in the Know 


Don’t miss out when something interesting happens! 
We've got a pattern that keeps your objects in the know when something they 
might care about happens. Objects can even decide at runtime whether they 
want to be kept informed. The Observer Pattern is one of the most heavily used 
patterns in the JDK, and it’s incredibly useful. Before we’re done, we'll also look 
at one to many relationships and loose coupling (yeah, that’s right, we said 


coupling). With Observer, you'll be the life of the Patterns Party. 
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Decorating Objects 


Just call this chapter “Design Eye for the Inheritance 
Guy.” We'll re-examine the typical overuse of inheritance and you'll learn how 
to decorate your classes at runtime using a form of object composition. Why? 
Once you know the techniques of decorating, you'll be able to give your (or 
someone else’s) objects new responsibilities without making any code changes 


to the underlying classes. 


Welcome to Starbuzz Coffee 
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at runtime, rather than at compile 
time. Now look at me! 
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the Factory Pattern 
Baking with OO Goodness 


Get ready to cook some loosely coupled OO designs. 
There is more to making objects than just using the new operator. You'll learn 
that instantiation is an activity that shouldn’t always be done in public and can 
often lead to coupling problems. And you don’t want that, do you? Find out how 


Factory Patterns can help save you from embarrasing dependencies. 
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the Singleton Pattern 


One of a Kind Objects 


The Singleton Pattern: your ticket to creating one-of-a- 
kind objects, for which there is only one instance. You 
might be happy to know that of all patterns, the Singleton is the simplest in terms 
of its class diagram; in fact the diagram holds just a single class! But don’t get 
too comfortable; despite its simplicity from a class design perspective, we'll 
encounter quite a few bumps and potholes in its implementation. So buckle 


up—this one’s not as simple as it seems... 
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the Command Pattern 


Encapsulating Invocation 


In this chapter we take encapsulation to a whole new 
level: we’re going to encapsulate method invocation. 
That’s right, by encapsulating invocation we can crystallize pieces of computation 
so that the object invoking the computation doesn’t need to worry about how to do 
things; it just uses our crystallized method to get it done. We can also do some 
wickedly smart things with these encapsulated method invocations, like save 


them away for logging or reuse them to implement undo in our code. 
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the Adapter and Facade Patterns 
Being Adaptive 


In this chapter we’re going to attempt such impossible 


feats as putting a square peg in a round hole. Sound impossible? 


Not when we have Design Patterns. Remember the Decorator Pattern? We 
wrapped objects to give them new responsibilities. Now we’re going to wrap some 
objects with a different purpose: to make their interfaces look like something they’re 
not. Why would we do that? So we can adapt a design expecting one interface to a 
class that implements a different interface. That’s not all, while we’re at it we’re going 


to look at another pattern that wraps objects to simplify their interface. 
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Encapsulating Algorithms 


We’ve encapsulated object creation, method invocation, 
complex interfaces, ducks, pizzas... what could be next? 
We're going to get down to encapsulating pieces of algorithms so that subclasses can 
hook themselves right into a computation anytime they want. We’re even going to 


learn about a design principle inspired by Hollywood. 
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the Iterator and Composite Patterns 


Well-Managed Collections 


There are lots of ways to stuff objects into a collection. 
Put them in an Array, a Stack, a List, a Map, take your pick. Each has its own 
advantages and tradeoffs. But when your client wants to iterate over your objects, 
are you going to show him your implementation? We certainly hope not! That just 
wouldn't be professional. Don’t worry—in this chapter you'll see how you can let 
your clients iterate through your objects without ever seeing how you store your 
objects. You’re also going to learn how to create some super collections of objects 
that can leap over some impressive data structures in a single bound. You’re also 


going to learn a thing or two about object responsibility. 
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the State Pattern 


The State of Things 


A little known fact: the Strategy and State Patterns were 
twins separated at birth. As you know, the Strategy Pattern went on 

to create a wildly successful business around interchangeable algorithms. State, 
however, took the perhaps more noble path of helping objects learn to control their 
behavior by changing their internal state. He’s often overheard telling his object 


clients, “just repeat after me, I’m good enough, I’m smart enough, and doggonit...” 
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the Proxy Pattern 


Controlling Object Access 


Ever play good cop, bad cop? You're the good cop and you provide 
all your services in a nice and friendly manner, but you don’t want everyone 
asking you for services, so you have the bad cop contro! access to you. That’s 
what proxies do: control and manage access. As you're going to see there are 
lots of ways in which proxies stand in for the objects they proxy. Proxies have 
been known to haul entire method calls over the Internet for their proxied objects; 


they’ve also been known to patiently stand in the place for some pretty lazy 


objects. 
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Compound Patterns 


Patterns of Patterns 


Who would have ever guessed that Patterns could work 
together? You've already witnessed the acrimonious Fireside Chats (and be 
thankful you didn’t have to see the Pattern Death Match pages that the publisher 
forced us to remove from the book so we could avoid having to use a Parent’s 
Advisory warning label), so who would have thought patterns can actually get along 
well together? Believe it or not, some of the most powerful OO designs use several 
patterns together. Get ready to take your pattern skills to the next level; it’s time for 
Compound Patterns. Just be careful—your co-workers might kill you if you’re struck 


with Pattern Fever. 
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Patterns in the Real World 


Ahhhh, now you’re ready for a bright new world filled with 
Design Patterns. But, before you go opening all those new doors of opportunity 
we need to cover a few details that you'll encounter out in the real world—things get a 
little more complex out there than they are here in Objectville. Come along, we've got 


a nice guide to help you through the transition... 
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Appendix: Leftover Patterns 


Not everyone can be the most popular. A lot has changed in 

the last 10 years. Since Design Patterns: Elements of Reusable Object-Oriented 
Software first came out, developers have applied these patterns thousands of times. 
The patterns we summarize in this appendix are full-fledged, card-carrying, official 
GoF patterns, but aren’t always used as often as the patterns we’ve explored so 

far. But these patterns are awesome in their own right, and if your situation calls for 
them, you should apply them with your head held high. Our goal in this appendix is 


to give you a high level idea of what these patterns are all about. 
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how to use this book 


Who is this book for? 


If you can answer “yes” to all of these: 


cbably be okay if 


@) Do you know Java? (You don’t need to be a guru.) You'll ol C4 instead. 


you know 


@) Do you want to learn, understand, remember, and 
apply design patterns, including the OO design 
principles upon which design patterns are based? 


Do you prefer stimulating dinner party conversation 
to dry, dull, academic lectures? 


this book is for you. 


Who should probably back away from this book? 


If you can answer “yes” to any one of these: 


@) Are you completely new to Java? 


(You don’t need to be advanced, and even if you 
don’t know Java, but you know C#, you'll probably 
understand at least 80% of the code examples. You 
also might be okay with just a C++ background.) 


@ Are you a kick-butt OO designer/developer looking 
for a reference book? 


® Are you an architect looking for enterprise design 
patterns? 


OC) Are you afraid to try something different? 
Would you rather have a root canal than mix 
stripes with plaid? Do you believe that a technical 
book can’t be serious if Java components are 
anthropomorphized? = 


this book is not for you. 


[note from marketing: this book is 
or anyone with a credit card.J 
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We know what youre thinking. 


“How can this be a serious programming book?” 
“What’s with all the graphics?” 


“Can I actually learn it this way?” 


And we know what your brain is thinking. ( 


Your brain craves novelty. It’s always searching, scanning, wazting for 
something unusual. It was built that way, and it helps you stay alive. 


Today, you’re less likely to be a tiger snack. But your brain’s still looking. You 
just never know. 


So what does your brain do with all the routine, ordinary, normal things 
you encounter? Everything it can to stop them from interfering with the 
brain’s real job—recording things that matter. It doesn’t bother saving the 
boring things; they never make it past the “this is obviously not important” 
filter. 


How does your brain Anow what’s important? Suppose youre out foraday sf . 
hike and a tiger jumps in front of you, what happens inside your head and 6a 


body? 


Great. Only 
637 more dull, dry, 
boring pages. 


Neurons fire. Emotions crank up. Chemicals surge. 


And that’s how your brain knows... 
bran rinks 


This must be important! Don’t forget it! you" wor ie. 


THIS isn 


ae ; er ; : 
But imagine you're at home, or in a library. It’s a safe, warm, tiger-free zone. saniny 


You’re studying. Getting ready for an exam. Or trying to learn some tough 
technical topic your boss thinks will take a week, ten days at the most. 


Just one problem. Your brain’s trying to do you a big favor. It’s trying _ to 
make sure that this obviously non-important content doesn’t clutter up 
scarce resources. Resources that are better spent storing the really bg 
things. Like tigers. Like the danger of fire. Like how you should never 


again snowboard in shorts. 


And there’s no simple way to tell your brain, “Hey brain, thank you 
very much, but no matter how dull this book is, and how little Pm 
registering on the emotional Richter scale right now, I really do want 
you to keep this stuff around.” 
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how to use this book 


1 


intro 


It really sucks to be an 
abstract method. You 
don't have a body. 


abstract voi 


ay! 
No qed 1 [ Get—and keep—the reader’s attention. We've ‘| 


We think of a “Head First’ reader as a learner. 


So what does it take to learn something? First, you have to getit, then make sure 
you don’t forget it. It’s not about pushing facts into your head. Based on the 
latest research in cognitive science, neurobiology, and educational psychology, 
learning takes a lot more than text on a page. We know what turns your brain on. 


Some of the Head First learning principles: 


needs to 
wethed cae Ral remote 
. . on « 
Make it visual. Images are far more memorable than words alone, and Seeven he service 


make learning much more effective (up to 89% improvement in recall and 
transfer studies). It also makes things more understandable. Put the 
words within or near the graphics they relate to, rather than on 


doCalc() 


the bottom or on another page, and learners will be up to twice as likely eeruenvalue 


to solve problems related to the content. 


Use a conversational and personalized style. In recent studies, students 
performed up to 40% better on post-learning tests if the content spoke directly to 
the reader, using a first-person, conversational style rather than taking a formal 
tone. Tell stories instead of lecturing. Use casual language. Don't take yourself 
too seriously. Which would you pay more attention to: a stimulating dinner party 
companion, or a lecture? 


Get the learner to think more deeply. In other words, unless 


et you actively flex your neurons, nothing much happens in your head. A 


Does it make sense to 

say Tub IS-A Bathroom? 
Bathroom IS-A Tub? Or is 
it a HAS-A relationship? 


reader has to be motivated, engaged, curious, and inspired to solve 
problems, draw conclusions, and generate new knowledge. And 


for that, you need challenges, exercises, and thought-provoking 
questions, and activities that involve both sides of the brain, 
roam() ; and multiple senses. 


End he ire all had the “I really want to learn this but | can’t stay awake past . 
era page one” experience. Your brain pays attention to things that 
are out of the ordinary, interesting, strange, eye-catching, unexpected. 7 | 
Learning anew, tough, technical topic doesn’t have to be boring. Your brain will 
learn much more quickly if it’s not. 


Touch their emotions. We now know that your ability to remember something is largely 
dependent on its emotional content. You remember what you care about. You remember 

when you feel something. No, we're not talking heart-wrenching stories about a boy and his 
dog. We're talking emotions like surprise, curiosity, fun, “what the...2", and the feeling of “I 

Rule!” that comes when you solve a puzzle, learn something everybody else thinks is hard, or 

realize you know something that “I’m more technical than thou" Bob from engineering doesn't. 
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Metacognition: thinking about thinking 


If you really want to learn, and you want to learn more quickly and more deeply, 


I wonder how I 
can trick my brain 
into remembering 
this stuff... 


growing up. We were expected to learn, but rarely taught to learn. > 


pay attention to how you pay attention. Think about how you think. Learn how you 
learn. 


Most of us did not take courses on metacognition or learning theory when we were 


But we assume that if you’re holding this book, you really want to learn design 
patterns. And you probably don’t want to spend a lot of time. And you want 
to remember what you read, and be able to apply it. And for that, you’ve got to 
understand it. To get the most from this book, or any book or learning experience, take 
responsibility for your brain. Your brain on éhs content. 


The trick is to get your brain to see the new material you’re learning as 
Really Important. Crucial to your well-being. As important as a tiger. 

Otherwise, you’re in for a constant battle, with your brain doing its best to 
keep the new content from sticking. 


So how DO you get your brain to think Design 
Patterns are as important as a tiger? 


There’s the slow, tedious way, or the faster, more effective way. The slow 
way is about sheer repetition. You obviously know that you ae able 

to learn and remember even the dullest of topics, if you keep pounding on the 
same thing. With enough repetition, your brain says, “This doesn’t feel important to him, 
but he keeps looking at the same thing over and over and over, so I suppose it must be.” 


The faster way is to do anything that increases brain activity, especially different 
types of brain activity. The things on the previous page are a big part of the solution, 
and they’re all things that have been proven to help your brain work in your favor. For 
example, studies show that putting words within the pictures they describe (as opposed to 
somewhere else in the page, like a caption or in the body text) causes your brain to try to 
makes sense of how the words and picture relate, and this causes more neurons to fire. 
More neurons firing = more chances for your brain to get that this is something worth 
paying attention to, and possibly recording. 


A conversational style helps because people tend to pay more attention when they 
perceive that they’re in a conversation, since they’re expected to follow along and hold up 
their end. The amazing thing is, your brain doesn’t necessarily care that the “conversation” 
is between you and a book! On the other hand, if the writing style is formal and dry, your 
brain perceives it the same way you experience being lectured to while sitting in a roomful 
of passive attendees. No need to stay awake. 


But pictures and conversational style are just the beginning. 


how to use this book 


Here's what WE did: 


We used pictures, because your brain 1s tuned for visuals, not text. As far as your brain’s 
concerned, a picture really 7s worth 1024 words. And when text and pictures work together, we 
embedded the text zm the pictures because your brain works more effectively when the text is 
within the thing the text refers to, as opposed to in a caption or buried in the text somewhere. 


We used redundancy, saying the same thing in different ways and with different media types, 
and multiple senses, to increase the chance that the content gets coded into more than one area of 
your brain. 


We used concepts and pictures in unexpected ways because your brain 1s tuned for novelty, 
and we used pictures and ideas with at least some emotional content, because your brain is 

tuned to pay attention to the biochemistry of emotions. That which causes you to feel something 
is more likely to be remembered, even if that feeling is nothing more than a little humor, 
surprise, or interest. 


We used a personalized, conversational style, because your brain is tuned to pay more 
attention when it believes you’re in a conversation than if it thinks you’re passively listening to a 
presentation. Your brain does this even when you're reading. 


We included more than 40 activities, because your brain 1s tuned to learn and remember 
more when you do things than when you read about things. And we made the exercises 
challenging-yet-do-able, because that’s what most people prefer. 


We used multiple learning styles, because you might prefer step-by-step procedures, while 
someone else wants to understand the big picture first, while someone else just wants to see a 
code example. But regardless of your own learning preference, everyone benefits from seeing the 
same content represented in multiple ways. 


We include content for both sides of your brain, because the more of your brain you 
engage, the more likely you are to learn and remember, and the longer you can stay focused. 
Since working one side of the brain often means giving the other side a chance to rest, you can 
be more productive at learning for a longer period of time. 


And we included stories and exercises that present more than one point of view, because 
your brain is tuned to learn more deeply when it’s forced to make evaluations and judgements. 


We included challenges, with exercises, and by asking questions that don’t always have 

a straight answer, because your brain is tuned to learn and remember when it has to work at 
something. Think about it—you can’t get your body in shape just by watching people at the gym. 
But we did our best to make sure that when you’re working hard, it’s on the mght things. That 
youre not spending one extra dendrite processing a hard-to-understand example, or 
parsing difficult, jargon-laden, or overly terse text. 


We used people. In stories, examples, pictures, etc., because, well, because youre a person. And 
P Pp 2 ‘Pp. eo) Pp. eo] p] e) | Jy Pp 
your brain pays more attention to /eople than it does to éhings. 


We used an 80/20 approach. We assume that if you’re going for a PhD in software design, this 
won't be your only book. So we don’t talk about everything. Just the stuff you'll actually need. 


XXX intro 


ONE TO MANY RELATIONSHIP 


Object that ia 


holds state 


> 


The Patterns Guru 


BULLET rom 


Puzzles 


eut this out a d sti F 
on Your re eee it 


Slow down. The more you understand, 
the less you have to memorize. 

Don’t just read. Stop and think. When the 
book asks you a question, don’t just skip to the 
answer. Imagine that someone really zs asking 
the question. The more deeply you force your 
brain to think, the better chance you have of 
learning and remembering. 


Do the exercises. Write your own notes. 
We put them in, but if we did them for you, 
that would be like having someone else do 

your workouts for you. And don’t just look at 

the exercises. Use a pencil. There’s plenty of 
evidence that physical activity while learning 
can increase the learning. 


Read the “There are No Dumb Questions” 
That means all of them. They’re not optional 
side-bars—they’re part of the core content! 
Don’t skip them. 


Make this the last thing you read before 


bed. Or at least the last challenging thing. 


Part of the learning (especially the transfer to 
long-term memory) happens after you put the 
book down. Your brain needs time on its own, to 
do more processing. If you put in something new 
during that processing-time, some of what you 
just learned will be lost. 


Drink water. Lots of it. 

Your brain works best in a nice bath of fluid. De- 
hydration (which can happen before you ever feel 
thirsty) decreases cognitive function. 
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Here's what YOU can do to bend 
your brain into submission 


So, we did our part. The rest is up to you. These tips are a 
starting point; listen to your brain and figure out what works 
for you and what doesn’t. Try new things. 


© Talk about it. Out loud. 


Speaking activates a different part of the brain. 
If you’re trying to understand something, or 
increase your chance of remembering it later, say 
it out loud. Better still, try to explain it out loud 
to someone else. You'll learn more quickly, and 
you might uncover ideas you hadn’t known were 
there when you were reading about it. 


Listen to your brain. 

Pay attention to whether your brain is getting 
overloaded. If you find yourself starting to skim the 
surface or forget what you just read, it’s time for a 
break. Once you go past a certain point, you won’t 
learn faster by trying to shove more in, and you 
might even hurt the process. 


Feel something! 

Your brain needs to know that this matters. Get 
involved with the stories. Make up your own cap- 
tions for the photos. Groaning over a bad joke is sitll 
better than feeling nothing at all. 


Design something! 

Apply this to something new you’re designing, or 
refactor an older project. Just do something to get 
some experience beyond the exercises and activities 
in this book. All you need is a pencil and a problem 
to solve... a problem that might benefit from one or 
more design patterns. 
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how to use this book 


Read Me 


This is a learning experience, not a reference book. We deliberately stripped out 
everything that might get in the way of learning whatever it is we’re working on at that 


point in the book. And the first time through, you need to begin at the beginning, becausewe yse 4 simples 
the book makes assumptions about what you’ve already seen and learned. modiried sl y) 
Director 


We use simple UML-like diagrams. 
getMovies 


Although there’s a good chance you’ve run across UML, it’s not covered in the book, and 
getOscars() 


it’s not a prerequisite for the book. If you’ve never seen UML before, don’t worry, we’ll 


getKevinBaconDegrees() 


give you a few pointers along the way. So in other words, you won’t have to worry about 
Design Patterns and UML at the same time. Our diagrams are “UML-lke” -- while we 
try to be true to UML there are times we bend the rules a bit, usually for our own selfish 
artistic reasons. 


We don’t cover every single Design Pattern ever created. 


There are a lot of Design Patterns: The original foundational patterns (known as the GoF 
patterns), Sun’s J2EE patterns, JSP patterns, architectural patterns, game design patterns 
and a Jot more. But our goal was to make sure the book weighed less than the person 
reading it, so we don’t cover them all here. Our focus is on the core patterns that matter 
from the original GoF patterns, and making sure that you really, truly, deeply understand 
how and when to use them. You will find a brief look at some of the other patterns (the 
ones youre far less likely to use) in the appendix. In any case, once you’re done with Head 
First Design Patterns, you'll be able to pick up any pattern catalog and get up to speed 
quickly. 


The activities are NOT optional. 


The exercises and activities are not add-ons; they’re part of the core content of the book. 
Some of them are to help with memory, some for understanding, and some to help you 
apply what you’ve learned. Don’t skip the exercises. The crossword puzzles are the 
only things you don’t have to do, but they’re good for giving your brain a chance to think 
about the words from a different context. 


We use the word “composition” in the general OO sense, which is 
more flexible than the strict UML use of “composition”. 


When we say “one object is composed with another object” we mean that they are related 
by a HAS-A relationship. Our use reflects the traditional use of the term and is the one 
used in the GoF text (you'll learn what that is later). More recently, UML has refined 

this term into several types of composition. If you are an UML expert, you'll still be able 
to read the book and you should be able to easily map the use of composition to more 
refined terms as you read. 
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The redundancy is intentional and important. 


One distinct difference in a Head First book is that we want you to veally get it. And we want 
you to finish the book remembering what you’ve learned. Most reference books don’t have 
retention and recall as a goal, but this book is about learning, so you'll see some of the same 
concepts come up more than once. 


The code examples are as lean as possible. 


Our readers tell us that it’s frustrating to wade through 200 lines of code looking for the two 
lines they need to understand. Most examples in this book are shown within the smallest 
possible context, so that the part you’re trying to learn is clear and simple. Don’t expect 

all of the code to be robust, or even complete—the examples are written specifically for 
learning, and aren’t always fully-functional. 


In some cases, we haven’t included all of the import statements needed, but we assume that 
if you’re a Java programmer, you know that ArrayList is in java.util, for example. If the 
imports were not part of the normal core J2SE API, we mention it. We’ve also placed all 
the source code on the web so you can download it. You’ll find it at 
http://www.wickedlysmart.com/headfirstdesignpatterns/code.html 


Also, for the sake of focusing on the learning side of the code, we did not put our classes 
into packages (in other words, they’re all in the Java default package). We don’t recommend 
this in the real world, and when you download the code examples from this book, you’ll find 
that all classes ave in packages. 


The ‘Brain Power’ exercises don’t have answers. 


For some of them, there is no right answer, and for others, part of the learning experience 
of the Brain Power activities is for you to decide if and when your answers are right. In 
some of the Brain Power exercises you will find hints to point you in the right direction. 
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In memory of Philippe Maquet 
1960-2004 


Your amazing technical expertise, relentless enthusiasm, and 
deep concern for the learner will inspire us always. 


We will never forget you. 


Philippe Maque 
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1 Intro to Design Patterns 


Welcome to * 
Design Patterns 


Now that we're living 
in Objectville, we've just got 
to get into Design Patterns... 
everyone is doing them. Soon 
well be the hit of Jim and 
Betty's Wednesday night 
“patterns group! 


Someone has already solved your problems. In this chapter, you'll learn 
why (and how) you can exploit the wisdom and lessons learned by other developers who’ve 
been down the same design problem road and survived the trip. Before we’re done, we'll 
look at the use and benefits of design patterns, look at some key OO design principles, and 
walk through an example of how one pattern works. The best way to use patterns is to load 
your brain with them and then recognize places in your designs and existing applications 


where you can apply them. Instead of code reuse, with patterns you get experience reuse. 


this is a new chapter 4 


SimUDuck 


It started with a simple SimUDuck app 


Joe works for a company that makes a highly successful duck pond 
sumulation game, S¢mUDuck. The game can show a large variety of 
duck species swimming and making quacking sounds. The initial 
designers of the system used standard OO techniques and created 
one Duck superclass from which all other duck types inherit. 


Duck 


All ducks quack and swim, the ——s quack() 
superclass takes eae of the 


swim() 


The display) method is 
abstract, since all duck 
subtypes look different. 


implementation code. display 
isplay 


// OTHER duck-like methods... 


wt a 
fa ore ow MallardDuck RedheadDuck Lots ok other tyre ek class 
i Xe ext" oie Kor disol displ + eit from the De 
ery tye eed isplay() { isplay() { mn 
gett \oo* on /I looks like a mallard } // looks like a redhead } 
yor * 
gexe® 


In the last year, the company has been under increasing pressure 
from competitors. After a week long off-site brainstorming 
session over golf, the company executives think it’s time for a big 
innovation. ‘They need something really impressive to show at the 
upcoming shareholders meeting in Maui next week. 
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But now we need the ducks to FLY 


The executives decided that flying ducks is just what the 
simulator needs to blow away the other duck sim competitors. 
And of course Joe’s manager told them it’ll be no problem 

for Joe to just whip something up in a week. “After all”, said 
Joe’s boss, “he’s an OO programmer... how hard can it be?” 


I just need to add a fly() 
method in the Duck class and 

then all the ducks will inherit it. 
Now's my time to really show my 
true OO genius. 


ne Joe 


Duck 
quack() 
swim() 
display() Joe added: 
ho, | fl what Je 
® aon | OTHER duck-like methods... 
A) 
MallardDuck RedheadDuck other Dutk ayer 
display() { display() { 


I looks like a mallard } /I looks like a redhead } 
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something went wrong 


But something went horribly wrong... 


Joe, I'm at the 
shareholder's meeting. 
They just gave a demo and there 
were rubber duckies flying around 
the screen. Was this your idea of 
a joke? You might want to spend 
some time on Monster.com... 


What happened? 


Joe failed to notice that not all 
subclasses of Duck should fly. When 
Joe added new behavior to the 
Duck superclass, he was also adding 
behavior that was not appropriate 
for some Duck subclasses. He now 
has flying inanimate objects in the 
SimUDuck program. 


OK, so there's a slight 
flaw in my design. I 

don't see why they can't 
just call it a “feature”. 
It's kind of cute... 


What he thought 


was a great use 


A localized update to the code caused a non- 
local side effect (flying rubber ducks)! 


of inheritance 


Duck 
quack() for the purpose 
pw swim() f dace 
a" eee a display() or reuse hasn 
Me OS | | turned out so well 
a spose On ILOTHER duck-like methods... 
“ee, when it comes to 
i or 7 ; 
oe maintenance. 
k, 
MallardDuck RedheadDuck RubberDuck Rubber ducks don aa 
display() { display() { quack() { <6 quatkl t over 
// looks like a mallard I! looks like a redhead / overridden to Squeak “Cqueak’ . 
} } } 


display() { 
|! looks like a rubberduck 


} 
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Joe thinks about inheritance... 


T could always just 
override the fly() method in 
rubber duck, the way I am with 
the quack() method... 


RubberDuck 


quack() { // squeak} 
display() { // rubber duck } 


fly() { 
[| override to do nothing 


} 
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But then what happens when 
we add wooden decoy ducks 
to the program? They aren't 

supposed to fly or quack... 


DecoyDuck 


quack() { 
// override to do nothing 


display() { // decoy duck} 
lass in the 
1, another © fly() { 
eee vais A ee : override to do nothing 
\ ak doesn 
bo c uty \ 
se oesh quack 


G harpen our pencil 
“ y 


Which of the following are disadvantages of using inheritance to 
provide Duck behavior? (Choose all that apply.) 


J A. Code is duplicated across subclasses. 


1 B. Runtime behavior changes are difficult. 


(J CG. We can’t make ducks dance. 


_] D. Hard to gain knowledge of all duck behaviors. 


_] E. Ducks can’t fly and quack at the same time. 


_J EF Changes can unintentionally affect other ducks. 
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inheritance is not the answer 


How about an interface? 


Joe realized that inheritance probably wasn’t the 
answer, because he just got a memo that says that 

the executives now want to update the product every 
six months (in ways they haven’t yet decided on). Joe 
knows the spec will keep changing and he’ll be forced 
to look at and possibly override fly() and quack() for 
every new Duck subclass that’s ever added to the 
program... forever. 


So, he needs a cleaner way to have only some (but not 
all) of the duck types fly or quack. 


swim() 
display() 


Quackable 
quack() 


Flyable 
fly() 


/ OTHER duck-like methods... 


I could take the fly() out of the 
Duck superclass, and make a 
Flyable() interface with a fly() 
method. That way, only the ducks that 
are supposed to fly will implement that 
interface and have a fly() method... and 
I might as well make a Quackable, too, 
since not all ducks can quack. 


MallardDuck RedheadDuck 


RubberDuck 


DecoyDuck 
display() display() display() display() 
fly() fly() quack() 
quack() quack() 


What do YOU think about this design? 


6 Chapter 1 


intro to Design Patterns 


That is, like, the dumbest idea 
you've come up with. Can you say, 
“duplicate code"? If you thought 
having to override a few methods was bad, 
how are you gonna feel when you need 
to make a little change to the flying 
behavior... in all 48 of the flying 
Duck subclasses?! 


- What would you do if you were Joe? 


We know that not all of the subclasses should have flying or quacking 
behavior, so inheritance isn’t the right answer. But while having 

the subclasses implement Flyable and/or Quackable solves part of 

the problem (no inappropriately flying rubber ducks), it completely 
destroys code reuse for those behaviors, so it just creates a different 
maintenance nightmare. And of course there might be more than one 
kind of flying behavior even among the ducks that do fly... 


At this point you might be waiting for a Design Pattern to come riding 
in on a white horse and save the day. But what fun would that be? No, 
we’re going to figure out a solution the old-fashioned way — by applying 
good OO software design principles. 


Wouldn't it be dreamy 

if there were a way to build 
software so that when we need to 
change it, we could do so with the least 
possible impact on the existing code? 
We could spend less time reworking 
code and more making the program 
do cooler things... 
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change is constant 


The one constant in software development 


Okay, what’s the one thing you can always count on in software development? 


No matter where you work, what you’re building, or what language you are programming in, what’s 
the one true constant that will be with you always? 


AOMAH 


(use a mirror to see the answer) 


No matter how well you design an application, over time an 
application must grow and change or it will de. 


erp your pencil 
IN Lots of things can drive change. List some reasons 
you've had to change code in your applications (we put 


in a couple of our own to get you started). 


My customers or users decide they want something else, or they want new functionality. 


My Company decided it is going with another database vendor and it is also purchasing 
its data from another supplier that uses a different data format. Argh! 


Zeroing in on the problem... 


So we know using inheritance hasn’t worked out very well, since 
the duck behavior keeps changing across the subclasses, and it’s 
not appropriate for all subclasses to have those behaviors. ‘The 
Flyable and Quackable interface sounded promising at first — only 
ducks that really do fly will be Flyable, etc — except Java interfaces 
have no implementation code, so no code reuse. And that means 
that whenever you need to modify a behavior, you’re forced to 
track down and change it in all the different subclasses where that 
behavior is defined, probably introducing new bugs along the way! 


Luckily, there’s a design principle for just this situation. 


Design Principle 


Identify the aspects of your 
application that vary and separate 
them from what stays the same. 


In other words, if you’ve got some aspect of your code that is 
changing, say with every new requirement, then you know you’ve 
got a behavior that needs to be pulled out and separated from all 
the stuff that doesn’t change. 


Here’s another way to think about this principle: take the parts 
that vary and encapsulate them, so that later you can 
alter or extend the parts that vary without affecting 
those that don’t. 


As simple as this concept is, it forms the basis for almost every 
design pattern. All patterns provide a way to let some part of a system 
vary independently of all other parts. 


Okay, time to pull the duck behavior out of the Duck classes! 
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Take what varies and 
“encapsulate” it so it won't 
affect the rest of your code. 


The result? Fewer 


unintended consequences 
from code changes and more 
flexibility in your systems! 


pull out what varies 


Separating what changes from what stays the same 


Where do we start? As far as we can tell, other than the problems with fly() and quack(), the Duck 
class is working well and there are no other parts of it that appear to vary or change frequently. 
So, other than a few slight changes, we’re going to pretty much leave the Duck class alone. 


Now, to separate the “parts that change from those that stay the same”, we are going to create two 
sets of classes (totally apart from Duck), one for fly and one for quack. Each set of classes will hold 
all the implementations of their respective behavior. For instance, we might have one class that 
implements quacking, another that implements squeaking, and another that implements silence. 


We know that fly() and quack() are the parts of the 
Duck class that vary across ducks. 


To separate these behaviors from the Duck class, we'll 
pull both methods out of the Duck class and create a 
new set of classes to represent each behavior. 


The Dutk class is still the superclass 
of all ducks, but we are pulling, out 


: d Various behavior 

d quack behaviors an ; . 
the fy an ere - ther tlass ; ekin eath et implementations are goind, 
putting the Now flying, and ve 9 9 to live here. 
structure: their own set of classes: : 


GRO 
Quick clos? “Wving Beron® 
: ot? 
Cuacking pen’ 
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Designing the Duck Behaviors 


So how are we going to design the set of classes that 
implement the fly and quack behaviors? 


We'd like to keep things flexible; after all, it was the inflexibility in 
the duck behaviors that got us into trouble in the first place. And we 
know that we want to assign behaviors to the instances of Duck. For 
example, we might want to instantiate a new MallardDuck instance 
and initialize it with a specific type of flying behavior. And while 
we’re there, why not make sure that we can change the behavior of a 
duck dynamically? In other words, we should include behavior setter 
methods in the Duck classes so that we can change the MallardDuck’s 
flying behavior at runtime. 


Given these goals, let’s look at our second design principle: 


Design Principle 


Program to an interface, not an 
implementation. 


We'll use an interface to represent each behavior — for instance, 
FlyBehavior and QuackBehavior — and each implementation of a 
behavior will implement one of those interfaces. 


So this time it won’t be the Duck classes that will implement the 
flying and quacking interfaces. Instead, we’ll make a set of classes 
whose entire reason for living is to represent a behavior (for example, 
“squeaking”’), and it’s the behavior class, rather than the Duck class, 
that will implement the behavior interface. 


This is in contrast to the way we were doing things before, where 

a behavior either came from a concrete implementation in the 
superclass Duck, or by providing a specialized implementation in the 
subclass itself. In both cases we were relying on an implementation. We 
were locked into using that specific implementation and there was no 
room for changing the behavior (other than writing more code). 


With our new design, the Duck subclasses will use a behavior 
represented by an interface (FlyBehavior and QuackBehavior), so that 
the actual implementation of the behavior (in other words, the specific 
concrete behavior coded in the class that implements the FlyBehavior 
or QuackBehavior) won’t be locked into the Duck subclass. 
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From now on, the Duck 
hehaviors will live in a 
separate class—a class that 
implements a particular 
hehavior interface. 


That way, the Duck classes 


won't need to know any ot 
the implementation details 
for their own behaviors. 


<<interface>> 
FlyBehavior 


fly() 


FlyWithWings FlyNoWay 


fly() { fly() { 
// implements duck flying // do nothing - can’t fly! 


} } 


‘ ge bara 
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program to an interface 


abstraey super 


be an abst 


type Could 


e 
interfoee ) Fact Class OR 


\ 


Animal 


makeSound() 


tonerete 
implementations 


I don't see why you have to 
use an interface for FlyBehavior. 
You can do the same thing with an 
abstract superclass. Isn't the 
whole point to use polymorphism? 


“Program to an interface” really means 
“Program to a supertype.” 


The word interface is overloaded here. ‘There’s the concept of 
interface, but there’s also the Java construct interface. You 

can program to an interface, without having to actually use a 

Java interface. The point is to exploit polymorphism by 
programming to a supertype so that the actual runtime object 
isn’t locked into the code. And we could rephrase “program to 

a supertype” as “the declared type of the variables should be a 
supertype, usually an abstract class or interface, so that the objects 
assigned to those variables can be of any concrete implementation 
of the supertype, which means the class declaring them doesn’t 
have to know about the actual object types!” 


This is probably old news to you, but just to make sure we’re 

all saying the same thing, here’s a simple example of using a 
polymorphic type — imagine an abstract class Animal, with two 
concrete implementations, Dog and Cat. 

Programming to an implementation would be: 


Declaring the variable “4” 
= ; ° 
pen . oe Dog () 7 ee a tontrete implementation 
. ; nimal/ +orces us to tod 
implementation, wee emt 


But programming to an interface /supertype would be: 
We know it’s a Dog, but 

new Dog () ; We Can now use the animal 

reterente polymorphically. 


Animal animal = 
animal .makeSound() ; 


Even better, rather than hard-coding the instantiation of the 
subtype (like new Dog()) into the code, assign the concrete 


Dog 


Cat 


implementation object at runtime: 


makeSound() { 
bark(); 


} 
bark() { // bark sound } 
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makeSound() { 
meow(); 


meow() { // meow sound } 


We don’t know WHAT the actual 


animal subtype is... all we care ab +t 
is that it k h . 
ou ow to respond to 


a = getAnimal(); 
a.makeSound() ; 
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Implementing the Duck Behaviors 


Here we have the two interfaces, FlyBehavior and QuackBehavior along with 


the corresponding classes that implement each concrete behavior: 


Came thing here Lor the quack 


ats inter ate 
gate te behaviors we have an INLET 
se an iter \\ 7 st includes a quack! 
Denavir oe 7 erent that jv eds to be 
NY Q vn) classes - peed te method that ne 
a N fn) a eet noo" implemented: 
new! \ne 
ample 
<<interface>> <<interface>> 
FlyBehavior QuackBehavior 
fly() quack() 
FlyWithWings FlyNoWay Quack Squeak MuteQuack 
M0 { . fly() { quack() { quack() { quack() { 
// implements duck flying // do nothing - can’t fly! implements duck quacking /| rubber duckie squeak Fdontiingeanthauechl 
} } 


Quacks that squeak. 


Quacks that make 
no sound at all. 


With this design, other types of objects can 
reuse our fly and quack behaviors because 
these behaviors are no longer hidden away 
in our Duck classes! 


And we can add new behaviors without 
modifying any of our existing behavior 
classes or touching any of the Duck classes 
that use flying behaviors. 


13 


behavior in a class 


thereyare_no 


Dumb Questions 


Q: Do | always have to implement my application first, see 
where things are changing, and then go back and separate & 
encapsulate those things? 


A: Not always; often when you are designing an application, 
you anticipate those areas that are going to vary and then go ahead 
and build the flexibility to deal with it into your code. You'll find 

that the principles and patterns can be applied at any stage of the 
development lifecycle. 


: Should we make Duck an interface too? 


A: Not in this case. As you'll see once we've got everything 
hooked together, we do benefit by having Duck not be an interface, 
and having specific ducks, like MallardDuck, inherit common 
properties and methods. Now that we've removed what varies from 
the Duck inheritance, we get the benefits of this structure without 
the problems. 


Ge sharpen your pencil 
Sal 


behavior that isn’t a duck? 
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Using our new design, what would you do if you needed to 
add rocket-powered flying to the SimUDuck app? 


2) Can you think of a class that might want to use the Quack 


Q: It feels a little weird to have a class that’s just a 
behavior. Aren’t classes supposed to represent things? Aren’t 
classes supposed to have both state AND behavior? 


A: In an OO system, yes, classes represent things that 
generally have both state (instance variables) and methods. And in 
this case, the thing happens to be a behavior. But even a behavior 
can still have state and methods; a flying behavior might have 
instance variables representing the attributes for the flying (wing 
beats per minute, max altitude and speed, etc.) behavior. 


‘(spunos Yonp soyxeUt yey} VdTAIpP 

v) [je yonp v ‘ojdurexa sug (Z 
“QOBPLOUL 

JoevyagAy] oy) syuswoydunr yey} 
SSLTI PALIMOGIOPIOYALT B WwIIy (| 


‘SIOMSUY 
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Integrating the Duck Behavior 


The key is that a Duck will now delegate its flying 
and quacking behavior, instead of using quacking and 
flying methods defined in the Duck class (or subclass). 


Here’s how: 


1) First we’ll add two instance variables to the Duck class called fly Behavior and 
quackBehavior, that are declared as the interface type (not a concrete class implementation 
type). Each duck object will set these variables polymorphically to reference the specific 
behavior type it would like at runtime (FlyWithWings, Squeak, etc.). 


We'll also remove the fly() and quack() methods from the Duck class (and any subclasses) 
because we’ve moved this behavior out into the FlyBehavior and QuackBehavior classes. 


We'll replace fly() and quack() in the Duck class with two similar methods, called 
performFly() and performQuack(); you’ll see how they work next. 


Instance variables hold a reference to 
a specific behavior at runtime. 


The behavior variables are 
declared as the behavior 
INTERFACE tyre. Dirck 


~~ FlyBehavior flyBehavior 
QuackBehavior quackBehavior 


These methods veplace 


KO. performQuack() 
Ay ane oe swim() 
display() 
i, performFly() 


// OTHER duck-like methods... 


, nor? 
Flying Bers” 
ot? 
Cuacking paws 


Duck Behaviors 


2) Now we implement performQuack(): ko something that 
e 


avior interkace: 


has a vererent 


public class Duck { Each ee 
QuackBehavior quackBehavior; <~ implements 
// more 


the QuackBeh 


handling, the quack behavior 


Rather than abet delegates that 
public void performQuack() { itself, the Due cn vekerenced by 
quackBehavior.quack(); behavigs cad a 
} quackbenavior 


} 


Pretty simple, huh? To perform the quack, a Duck just allows the object that 
is referenced by quackBehavior to quack for it. 

In this part of the code we don’t care what kind of object it is, all we care 
about is that it knows how to quack()! 
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integrating duck behavior 


More Integration... 


3) Okay, time to worry about how the flyBehavior and 
quackBehavior instance variables are set. Let’s take a look at 
the MallardDuck class: 


ne Quack class iy 


ublic class MallardDuck extends Duck 
# \lardDuck uses 4 wack 
h Ma 


public MallardDuck() { handle its ach 5° pe Lor the quack is 
quackBehavior = new Quack(); is called, the respons! Ke een and we 9€ 
flyBehavior = new FlyWithWings(); delegated te the Sv y 
3 veal quack: 4, PyBawser 
Remember, MallardDuck inherits the Oe ait wees FlyWithWings as its FY 
quatkBehavior and flyBehavior instance Aw 
variables from class Duck. type: 


public void display() { 
System.out.printin(“I’m a real Mallard duck”); 
} 


So MallardDuck’s quack is a real live duck quack, not a squeak and 
not a mute quack. So what happens here? When a MallardDuck 
is instantiated, its constructor initializes the MallardDuck’s inherited 
quackBehavior instance variable to a new instance of type Quack (a 
QuackBehavior concrete implementation class). 


And the same is true for the duck’s flying behavior — the MallardDuck’s 
constructor initializes the flyBehavior instance variable with an instance 
of type FlyWithWings (a FlyBehavior concrete implementation class). 
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Wait a second, didn't you 
say we should NOT program to an 
implementation? But what are we doing 
in that constructor? We're making a 
new instance of a concrete Quack 
implementation class! 


Good catch, that’s exactly what we’re doing... 
Sor now. 


Later in the book we’ll have more patterns in 
our toolbox that can help us fix it. 


Still, notice that while we ave setting the 
behaviors to concrete classes (by instantiating 
a behavior class like Quack or FlyWithWings 
and assigning it to our behavior reference 
variable), we could easily change that at 
runtime. 


So, we still have a lot of flexibility here, 

but we’re doing a poor job of initializing 

the instance variables in a flexible way. But 
think about it, since the quackBehavior 
instance variable is an interface type, we 
could (through the magic of polymorphism) 
dynamically assign a different QuackBehavior 
implementation class at runtime. 


Take a moment and think about how you 
would implement a duck so that its behavior 
could change at runtime. (You'll see the code 
that does this a few pages from now.) 


testing duck behaviors 


Testing the Duck code 


1) Type and compile the Duck class below (Duck.java), and the 
MallardDuck class from two pages back (MallardDuck.java). 


ublic abstract class Duck : 
| Declare two reference variables 


. . es. 
FlyBehavior flyBehavior; <— Lor the behavior interface typ 
QuackBehavior quackBehavior; All duck subclasses (in the same 
public Duck() { package) inherit these: 


} 
public abstract void display(); 


public void performFly() { 


flyBehavior.fly(); ce#“—_ Delegate to the behavior ¢lass. 
} 


public void performQuack() { 
quackBehavior.quack (); 


} 


public void swim() { 
System.out.printlin(“All ducks float, even decoys!”); 


} 


(2) Type and compile the FlyBehavior interface (FlyBehavior.java) and 
the two behavior implementation classes (FlyWithWings.java and 
FlyNoWay.java). 

The interface that all Ayn 


public interface FlyBehavior { behavior Classes implemen 
public void fly(); 
} 


public class FlyWithWings implements FlyBehavior { 8 lementation 

public void fly() { Flying behavior eae 
System.out.println (“I'm flying!!”); Lor ducks that DO *ly- 

} 

} 

public pre ee. EE oway implements FlyBehavior { Flying bebo: 
public void fly() { Set ro implementation 
System.out.println(“I can’t fly”); vubbice i do NOT Aly (lik 


} 


18 Chapter 1 


intro to Design Patterns 


Testing the Duck code continued... 


3) Type and compile the QuackBehavior interface 
(QuackBehavior.java) and the three behavior implementation 
classes (Quack.java, MuteQuack.java, and Squeak.java). 


public interface QuackBehavior { 
public void quack(); 
} 


public class Quack implements QuackBehavior { 
public void quack() { 
System. out.printlin (“Quack”) ; 
} 


public class MuteQuack implements QuackBehavior { 
public void quack() { 
System.out.printlin(“<< Silence >>”); 


} 


public class Squeak implements QuackBehavior { 
public void quack() { 
System.out.printlin(“Squeak”) ; 
} 
} 


4) Type and compile the test class 
(MiniDuckSimulator.java). 


public class MiniDuckSimulator { 
public static void main(String[] args) { ¢ O 
. . ormQuack! 
Duck mallard = new MallardDuck(); — Tye galls the MallardDuek’s inherited per 


mallard.performQuack () ; —<— nethod, which then delegates to the ober 
m ? 
ice cea ae ad QuackBehavior (i.e. calls quack() on the ducks 


| inherited quackBehavior reference): 


i k’s 
me thing with MallardDue! 
: Then we do the same 
° ee inherited performPly0) method. 


| File Edit Window Help Yadayadayada 
Sjava MiniDuckSimulator 


Quack 


I’m flying! ! 
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ducks with dynamic behavior 


Setting behavior dynamically 


What a shame to have all this dynamic talent built into our ducks and not be using 
it! Imagine you want to set the duck’s behavior type through a setter method on the 
duck subclass, rather than by instantiating it in the duck’s constructor. 


® Add two new methods to the Duck class: 


public void setFlyBehavior(FlyBehavior fb) { 
flyBehavior = fb; 


} Duck 
FlyBehavior flyBehavior; 
public void setQuackBehavior (QuackBehavior qb) { QuackBehavior quackBehavior; 


quackBehavior = qb; swim() 


display() 
performQuack() 
performFly() 
setFlyBehavior() 


setQuackBehavior() 
/| OTHER duck-like methods... 


We can call these metho 
behavior of a duc 


nytime we want to change the 


editor note: gratuitous pun - fix 


(2) Make a new Duck type (ModelDuck.java). 


public class ModelDuck extends Duck { ans like grounded 
public ModelDuck() { Our ™ bo BY. 
flyBehavior = new FlyNoWay(); ——— without a way Y 


quackBehavior = new Quack (); 


public void display() { 
System.out.println(“I’m a model duck”); 


s okay, we're Creating a 
3) Make a new FlyBehavior type That's okay, were 9 


rotket powered flying behavior 
(FlyRocketPowered.java). os 


public class FlyRocketPowered implements FlyBehavior { 
public void fly() { 
System.out.println(“I’m flying with a rocket!”); 
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Change the test class (MiniDuckSimulator.java), add the 
ModelDuck, and make the ModelDuck rocket-enabled. 


before 


public class MiniDuckSimulator { 
public static void main(String[] args) { 
Duck mallard = new MallardDuck(); 


mallard.performQuack () ; | EEEERPR\ 


mallard.performFly(); \ = salt to pevformPlyO 7 
ie fyBehavior abject set ee _ 
Duck model = new ModelDuck(); ModelDutt’'s tonsbructer whie! 


model .performFly () ; ee FlyNoWay instante: 


model.setFlyBehavior (new FlyRocketPowered () ); < Hhis invokes the model’s inherited 


ania . behavior set-tey method, and...voilal Th 
model suddenly has rotket—powered ; 

If it worked, the model se a 
changed its Alying behavi 
if the implementation 


duck dynamically 
; or! You can’t do THAT 
lives inside the duek élass. 


Sjava MiniDuckSimulator 


Quack 


I’m flying! ! 


I can’t fly 


I’m flying with a rocket! 


To change a duck’s 
behavior at runtime, just 


call the duck’s setter 
method for that behavior. 
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the big picture 


The Big Picture on encapsulated behaviors 


Okay, now that we’ve done the deep dive on the 
duck simulator design, it’s time to come back up 
for air and take a look at the big picture. 


Below 1s the entire reworked class structure. We have everything you'd expect: 
ducks extending Duck, fly behaviors implementing FlyBehavior and quack 
behaviors implementing QuackBehavior. 


Notice also that we’ve started to describe things a little differently. Instead 
of thinking of the duck behaviors as a set of behaviors, we'll start thinking of 
them as a family of algorithms. Think about it: in the SimU Duck design, the 
algorithms represent things a duck would do (different ways of quacking or 
flying), but we could just as easily use the same techniques for a set of classes 
that implement the ways to compute state sales tax by different states. 


Pay careful attention to the relationships between the classes. In fact, grab 
your pen and write the appropriate relationship (IS-A, HAS-A and 
IMPLEMENTS) on each arrow in the class diagram. 


Client makes use of an 
encapsulated family of algorithms 
for both ying, and quacking, 


Encapsulated fly behavior 


<<interface>> 
FlyBehavior 


FlyBehavior flyBehavior FlyWithWings FlyNoWay_ 
QuackBehavior quackBehavior fly() { fly() { 
//implements duck flying 


} } 


jing - can't fly! 
swim() /I do nothing - can't fly! 


display() 
performQuack() 
performFly() 
sotFiyehavior) Encapsulated quack behavior 
<<interface>> 
QuackBehavior 
quack() 


setQuackBehavior() 
I OTHER duck-like methods... 


N ; . 


MallardDuck 


RedheadDuck 


RubberDuck 


DecoyDuck 


display() { 
I looks like a mallard } 


display() { 
Il looks like a redhead } 
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display() { 
I looks like a rubberduck } 


display() { 
I looks like a decoy duck } 


Quack 


Squeak 


MuteQuack 


quack) { 
/limplements duck quacking 


} 


quack() { 
// rubber duckie squeak 


} 


quack() { 
|! do nothing - can’t quack! 


{NN 5 fl s \e- 
Ry Joe on ea? 
a\) 


HAS-A can be better than IS-A 


The HAS-A relationship is an interesting one: each duck 
has a FlyBehavior and a QuackBehavior to which it 
delegates flying and quacking. 


When you put two classes together like this you’re using 
composition. Instead of inheriting their behavior, the 
ducks get their behavior by being composed with the right 
behavior object. 


This is an important technique; in fact, we’ve been using 
our third design principle: 


Design Principle 


Favor composition over inheritance. 


As you've seen, creating systems using composition gives you 
a lot more flexibility. Not only does it let you encapsulate 

a family of algorithms into their own set of classes, but it 
also lets you change behavior at runtime as long as 

the object you’re composing with implements the correct 
behavior interface. 


Composition is used in many design patterns and you'll 
see a lot more about its advantages and disadvantages 
throughout the book. 


ER ALN 
TPOWER 


A duck call is a device that hunters use to mimic the 
calls (quacks) of ducks. How would you implement your 


own duck call that does not inherit from the Duck class? 


a. 
: 
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Master and Student... 


»zm, Master: Grasshopper, 

4 tell me what you have 
» learned of the Object- 

Oriented ways. 


Student: Master, | have learned that 
the promise of the object-oriented way 
is reuse. 


Master: Grasshopper, continue... 


Student: Master, through inheritance 
all good things may be reused and 
so we will come to drastically cut 
development time like we swiftly cut 
bamboo in the woods. 


Master: Grasshopper, is more 
time spent on code before or after 
development is complete? 


Student: The answer is after, 
Master. We always spend more time 
maintaining and changing software 
than on initial development. 


Master: So Grasshopper, should effort : 
go into reuse above maintainability and : 
extensibility? : 
Student: Master, | believe that there is 
truth in this. 


Master: | can see that you still have 
much to learn. | would like for you to 
go and meditate on inheritance further. 
As you've seen, inheritance has its 
problems, and there are other ways of 
achieving reuse. 


the strategy pattern 


Speaking of Design Patterns... 


Congratulations on 
your first pattern! 


You just applied your first des:gn pattern—the 
STRATEGY pattern. That’s right, you used the 
Strategy Pattern to rework the SimUDuck app. 
Thanks to this pattern, the simulator is ready for any 
changes those execs might cook up on their next 
business trip to Maui. 


Now that we’ve made you take the long road to apply it, 
here’s the formal definition of this pattern: 


Leon WHe™ hie 
The Strategy Pattern defines a family of algorithms, WS gefintem ds and 
encapsulates each one, and makes them interchangeable. Wet igre etn 
Strategy lets the algorithm vary independently from wee ate Nl © 


; : fives 
clients that use it. * 
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intro to Design Patterns 


Below you'll find a mess of classes and interfaces for an action adventure game. You'll 
find classes for game characters along with classes for weapon behaviors the characters 
can use in the game. Each character can make use of one weapon at a time, but can 
change weapons at any time during the game. Your job is to sort it all out... 


(Answers are at the end of the chapter.) 


Your task: 


1) Arrange the classes. 


(2) Identify one abstract class, one interface and eight classes. 


3) Draw arrows between classes. 


a. Draw this kind of arrow for inheritance (“extends”). ~~ 


b. Draw this kind of arrow for interface (“implements”). ........-/ ~~ 


c. Draw this kind of arrow for “HAS-A’. ———> 


e Put the method setWeapon() into the right class. 


Character 
WeaponBehavior weapon; 


fight(); KnifeBehavior 


BowAndArrowBehavior 


useWeapon() { // implements cutting 


useWeapon() { // implements shoot- 


with a knife } <<interface>> 
a WeaponBehavior 
useWeapon(); 


w with a bow } 


Troll 


AxeBehavior 


fight() { .. } 
Knight 


SwordBehavior 


useWeapon() { // implements chop- 
ping with an axe } 


fight() {... } 
ing a sword } 


setWeapon (WeaponBehavior w) { 
this.weapon = w; 


useWeapon() { // implements swing- 


you are here > 
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diner 


Overheard at the local diner... 


Alice 


I need a Cream cheese 
with jelly on white bread, a 
chocolate soda with vanilla ice cream, a 
grilled cheese sandwich with bacon, a tuna 
fish salad on toast, a banana split with 

ice cream & sliced bananas and a coffee 
with a cream and two sugars, ... oh, 
and put a hamburger on the grill! 


Flo 


Give mea C.J. 
White, a black & white, a 
Jack Benny, a radio, a house 
boat, a coffee regular and 
burn onel 


— 


I 


What’s the difference between these two orders? Not a thing! They’re both 
the same order, except Alice is using twice the number of words and trying the 
patience of a grumpy short order cook. 


What’s Flo got that Alice doesn’t? A shared vocabulary with the short order 
cook. Not only is it easier to communicate with the cook, but it gives the cook less 
to remember because he’s got all the diner patterns in his head. 


Design Patterns give you a shared vocabulary with other developers. Once you’ve 
got the vocabulary you can more easily communicate with other developers and 
inspire those who don’t know patterns to start learning them. It also elevates your 
thinking about architectures by letting you think at the pattern level, not the 
nitty gritty object level. 
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Overheard in the next cubicle... 


So I created this broadcast 
class. It keeps track of all 
the objects listening to it and anytime 
a new piece of data comes along it sends a 
message to each listener. What's cool is that 
the listeners can join the broadcast at any 
time or they can even remove themselves. 
It is really dynamic and loosely-coupled! 


WAL 
POWER 


Can you think of other shared vocabularies 
that are used beyond OO design and diner 
talk? (Hint: how about auto mechanics, 

carpenters, gourmet chefs, air traffic control). 
What qualities are communicated along with 
the lingo? 


Can you think of aspects of OO design 
that get communicated along with pattern 

names? What qualities get communicated 
along with the name “Strategy Pattern”? 


Exactly. If you 
communicate in patterns, 
then other developers know 
immediately and precisely the 
design you're describing. Just don't 
get Pattern Fever... you'll know 
you have it when you start using 
patterns for Hello 
World... 


Rick, why 
didn't you just say 
you were using the 
Observer Pattern? 
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shared vocabulary 


The power of a shared pattern vocabulary 
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When you communicate using patterns you 


are doing more than just sharing LINGO. 


Shared pattern vocabularies are POWERFUL. 
When you communicate with another developer or your 
team using patterns, you are communicating not just a 
pattern name but a whole set of qualities, characteristics 
and constraints that the pattern represents. 


Patterns allow you to say more with less. When 
you use a pattern in a description, other developers quickly 
know precisely the design you have in mind. 


Talking at the pattern level allows you to stay “in 
the design” longer. ‘Talking about software systems using 
patterns allows you to keep the discussion at the design 
level, without having to dive down to the nitty gritty details 
of implementing objects and classes. 


Shared vocabularies can turbo charge your 
development team. A team well versed in design 
patterns can move more quickly with less room for 
misunderstanding. 


Shared vocabularies encourage more junior 
developers to get up to speed. Junior developers look 
up to experienced developers. When senior developers 
make use of design patterns, junior developers also become 
motivated to learn them. Build a community of pattern 
users at your organization. 


Chapter 1 


Lew 
bye strated ead of out 
“we've usin ¢ variovs b * tk behavior 
aioe kells Yu ¢ own SC 
utks- \ar ea Ww a 
tars ; panded 
has een at can Pe east] C weeded 
classes d, ever at cunt wh 
change! ) 
ial al 
ocr ewer 
ges" ade 
oe 
pon OO 


ins to share design 
te in terms © 


build a Community 


As your team be 
ideas and experien 
P atterns, you will 
of patterns users: 


Think about starting a patterns study 
group at your organization, maybe you 
tan even get paid while you're learning... 
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How do | use Design Patterns? 


We've all used off-the-shelf libraries and frameworks. We take them, write some code against their APIs, 
compile them into our programs, and benefit from a lot of code someone else has written. ‘Think about 
the Java APIs and all the functionality they give you: network, GUI, IO, etc. Libraries and frameworks go 
a long way towards a development model where we can just pick and choose components and plug them 
right in. But... they don’t help us structure our own applications in ways that are easier to understand, more 
maintainable and flexible. That’s where Design Patterns come in. 

Design patterns don’t go directly into your code, they first go into your BRAIN. Once you’ve loaded your 


brain with a good working knowledge of patterns, you can then start to apply them to your new designs, 
and rework your old code when you find it’s degrading into an inflexible mess of jungle spaghetti code. 


2 

& 

ry 

fates ete ae OBSERVER 
% “ e 

3 ©): : am a 
7 La 

Automatie update/notification ie 
he 
thereyare_no 
Dumb Questions 
Q: If design patterns are so great, > Aren't libraries and frameworks understand APIs that are structured 


why can’t someone build a library of also design patterns? around design patterns. 


them so | don’t have to? 


A: Design patterns are higher level 
than libraries. Design patterns tell us 
how to structure classes and objects to 
solve certain problems and it is our job to 
adapt those designs to fit our particular 
application. 


A: Frameworks and libraries are not 
design patterns; they provide specific 
implementations that we link into our 
code. Sometimes, however, libraries and 
frameworks make use of design patterns 
in their implementations. That’s great, 
because once you understand design 
patterns, you'll more quickly 


: So, there are no libraries of 
design patterns? 


A: No, but you will learn later about 
pattern catalogs with lists of patterns that 
you can apply to your applications. 
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why design 


Skeptical Developer 
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patterns? 


Patterns are 
nothing more than using 
OO design principles... 


A common misconception, 
Grasshopper, but it's more 
subtle than that. You have 
much to learn... 


Friendly 
Patterns Guru 


Developer: Okay, hmm, but isn't this all just good object-oriented design; I mean 
as long as I follow encapsulation and I know about abstraction, inheritance, and 
polymorphism, do I really need to think about Design Patterns? Isn't it pretty 
straightforward? Isn't this why I took all those OO courses? I think Design 
Patterns are useful for people who don't know good OO design. 


Guru: Ah, this is one of the true misunderstandings of object-oriented 
development: that by knowing the OO basics we are automatically going to be good at 
building flexible, reusable, and maintainable systems. 


Developer: No? 


Guru: No. As it turns out, constructing OO systems that have these properties is 
not always obvious and has been discovered only through hard work. 


Developer: I think I'm starting to get it. These, sometimes non-obvious, ways of 
constructing object-oriented systems have been collected... 


Guru: .. yes, into a set of patterns called Design Patterns. 


Developer: So, by knowing patterns, I can skip the hard work and jump straight to 
designs that always work? 


Guru: Yes, to an extent, but remember, design is an art. There will always be 
tradeoffs. But, if you follow well thought-out and time-tested design patterns, you'll 
be way ahead. 


Developer: What do I do if I can't find a pattern? 


intro to Design Patterns 


Remember, knowing 
concepts like abstraction, 
inheritance, and polymorphism do 
not make you a good object oriented 
designer. A design guru thinks about 
how to create flexible designs that 
are maintainable and that can 
cope with change. 


Guru: There are some object oriented-principles that 
underlie the patterns, and knowing these will help you 
to cope when you can't find a pattern that matches your 
problem. 


Developer: Principles? You mean beyond abstraction, 
encapsulation, and... 


Guru: Yes, one of the secrets to creating maintainable 


OO systems is thinking about how they might change in the 
future and these principles address those issues. 
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Tools for your Design Toolbox 


You’ve nearly made it through the first 
chapter! You’ve already put a few tools 
in your OO toolbox; let’s make a list of 
them before we move on to Chapter 2. 


wae eee basis 
jou Ene wally 
: We assume TP clymorgie 
00 Basies ok usin on iy Vike des *Y 
how anneritan 4 nearsuation 
Hlosbraction —" contract a ave aad ae 
5 {o) V 
Encapsulation ee val nas . his 
: ) en Aw 
Poly morpnis™ aon 56 ven 
Inheritance garter age 
06 Principles 
look. at 
; ki 3 closer 
2 cake . tke oad and a 
these — ace to the list 
3 A ding, a en mm 
Throughout the 


book think about 
how patterns vely 
on 00 basics and 
principles. 


One down, many to go! 
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r BULLET es —_ 


Knowing the OO basics 
does not make you a good 
OO designer. 


Good OO designs are 
reusable, extensible and 
maintainable. 


Patterns show you how to 
build systems with good 
OO design qualities. 


Patterns are proven object- 
oriented experience. 


Patterns don’t give you 
code, they give you 
general solutions to design 
problems. You apply them 
to your specific application. 


Patterns aren't invented, 
they are discovered. 


Most patterns and 
principles address issues of 
change in software. 


Most patterns allow some 
part of a system to vary 
independently of all other 
parts. 


We often try to take what 
varies in a system and 
encapsulate it. 


Patterns provide a 

shared language that can 
maximize the value of your 
communication with other 
developers. 


intro to Design Patterns 


Let’s give your right brain something to do. 
It’s your standard crossword; all of the solution words 


are from this chapter. 


Across 

2 what varies 
4. Design patterns 
6. Java |O, Networking, Sound 

9. Rubberducks make a 

13. Bartender thought they were called 

15. Program to this, not an implementation 
17. Patterns go into your 

18. Learn from the other guy's 

19. Development constant 

20. Patterns give us a shared 


Down 

1. Patterns in many applications 
3. Favor over inheritance 

5. Dan was thrilled with this pattern 
7. Most patterns follow from OO 

8. Not your own 

10. High level libraries 

11. Joe's favorite drink 

12. Pattern that fixed the simulator 
13. Duck that can't quack 

14. Grilled cheese with bacon 

16. Duck demo was located where 
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design puzzle solution 


KB Design Puzzle Solution 


Character is the abstract class for all the other characters (King, Queen, 
Knight and Troll) while WeaponBehavior is an interface that all weapon 
behaviors implement. So all actual characters and weapons are concrete 
classes. 


To switch weapons, each character calls the setWeapon() method, which 
is defined in the Character superclass. During a fight the useWeapon() 
method is called on the current weapon set for a given character to inflict 
great bodily damage on another character. 


abstract 


Character 


WeaponBehavior weapon; 
fight(); 
setWeapon(WeaponBehavior w) { 


this.weapon = w; 


King Knight 
fight() { ... } fight() { ... } 


fA Character HAS-A 
WeaponBehavior. 


fight() {... } 


<<interface>> 
WeaponBehavior 


useWeapon(); 


ao SY. 


SwordBehavior : BowAndArrowBehavior 
useWeapon() {// implements swing- useWeapon() {// implements shoot- 
ing a sword } 


KnifeBehavior ae Axabahavlot 


useWeapon() { // implements cutting useWeapon() {// implements chop- 
ee with a knife } ping with an axe } 
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Solutions 


Gedharpen your pencil 
“aia 


Which of the following are disadvantages of using subclassing to provide specific 
Duck behavior? (Choose all that apply.) 


YW A. Code is duplicated across subclasses. wp. Hard to gain knowledge of all duck behaviors. 
B. Runtime behavior changes are difficult. [4 E. Ducks can’t fly and quack at the same time. 


(YG. We can’t make duck’s dance. Wr Changes can unintentionally affect other ducks. 
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have a very different list, but here’s a few of ours. Look familiar? 


G harpen your pencil What are some factors that drive change in your applications? You might 


My customers or users decide they want something else, or they want new functionality. 


My Company decided it is going with another database vendor and it is also purchasing its data 
from another supplier that uses a different data format. Argh! 


Well, technology changes and we've got to update our code to make use of prototols. 
We've learned enough building our system that we'd like to go back and do things a little better. 


‘ ge i en 
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2 the Observer Pattern 


Keeping your * + 
* Objects in the know 


- — 


Hey Jerry, I'm 
notifying everyone that the 
Patterns Group meeting moved to 
Saturday night. We're going to be 
talking about the Observer Pattern. 
That pattern is the best! It's the 
BEST, Jerry! 


Don’t miss out when something interesting happens! We've got a 
pattern that keeps your objects in the know when something they might care about happens. 
Objects can even decide at runtime whether they want to be kept informed. The Observer 
Pattern is one of the most heavily used patterns in the JDK, and it’s incredibly useful. Before 
we’re done, we'll also look at one to many relationships and loose coupling (yeah, that’s right, 
we said coupling). With Observer, you'll be the life of the Patterns Party. 
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weath ‘ 
er monitoring statio 
station 


Congratulations! 


Your te 
am has j 
Weather-O-R eg won the contract t 
generation 
3 


Internet 
-bas 
ed Weather Monitoring S 
tation. 


Weather-O-Ram2 Inc. 
400 Main Street 
Tornado Alley: OK 45021 


statement of Work 
Congratulatt on being selected to puild our next generation 
Internet-ba eather Monitoring Station 


We look forward to seeing your design and alpha application. 


sincerely; 


Johnny Hurricane, CEO 
ps. We are overnighting the WeatherData source files to you. 
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the observer pattern 


The Weather Monitoring application overview 


The three players in the system are the weather station (the physical device that 
acquires the actual weather data), the WeatherData object (that tracks the data coming 


from the Weather Station and updates the displays), and the display that shows users vk 
vtions 1s On 


displays: The 
4 weather stats 


the current weather conditions. Current Cond 
Kye different 


yser can also 9¢ 


and 3 asd BP 


displays 


Humidity 
sensor device 


O— 


Temperature 
sensor device 


} Current 
Conditions 
Temp: 72° 

Humidity: 60 


LED pulls data 


WeatherData 
object 


Weather Station ses ; 
Display device 


Pressure 
sensor device 


Weather-O-Rama provides What we implement 


The WeatherData object knows how to talk to the physical Weather Station, to get 
updated data. The WeatherData object then updates its displays for the three different 
display elements: Current Conditions (shows temperature, humidity, and pressure), 
Weather Statistics, and a simple forecast. 


Our job, if we choose to accept it, is to create an app that 
uses the WeatherData object to update three displays for 
current conditions, weather stats, and a forecast. 


weather data class 


Unpacking the WeatherData class 


As promised, the next morning the WeatherData source files arrive. 
Peeking inside the code, things look pretty straightforward: 


ewe e, hun’ 
WeatherData hese twee meth - Gor temper a) 
{Te gather ™ ase" svi esgettnen 

ge emperature() we acometrit pre ve seks 
getHumidity() and wow these varia L update 
getPressure() dont C86 Tt ynows he 

We advice ion 

weather D2e weather SA 


measurementsChanged() 


// other methods 


This method gets called 
whenever the weather measurements 
have been updated 


WeatherData * 
lopers of the if 
-_ Le us a Clue about what we public void measurementsChanged() { 
objet a // Your code goes here 
need to a } 


Remember, this Curr WeatherData java 


nt Con Itions is } 
ONE of three ; ¢e d t S S just 


ifferent display sereens. 


Condifione Our job is to implement measurementsChanged() 
Temp: 72° so that it updates the three displays for current 
Humidity: 60 conditions, weather stats, and forecast. 


Display device 
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What do we know so far? 


The spec from Weather-O-Rama wasn’t all that clear, but we have to 
figure out what we need to do. So, what do we know so far? 


etTemperature 
<x The WeatherData class has getter methods for three is 0 


measurement values: temperature, humidity and getHumidity () 
barometric pressure. getPressure () 


<x The measurementsChanged() method is called any 
time new weather measurement data is available. (We 
don’t know or care how this method is called; we just 
know that it /s.) 


measurementsChanged () 


Weather 
Stats 


<x We need to implement three display elements that 
use the weather data: a current conditions display, a 
Statistics display and a forecast display. These displays 
must be updated each time WeatherData has new 
measurements. 


Temp: 72° 
Humidity: 6 
Pressure: 


Display One 


Display Three 


x The system must be expandable—other developers 
can create new custom display elements and users 
can add or remove as many display elements as they 
want to the application. Currently, we know about 
only the initial three display types (current conditions, 
statistics and forecast). 


eo 


Future displays 


first try with the weather station 


Taking a first, misguided SWAG at 
the Weather Station 


Here’s a first implementation possibility—we’ll take the hint from the Weather-O- 
Rama developers and add our code to the measurementsChanged() method: 


public class WeatherData { 
// instance variable declarations 


public void measurementsChanged() { 
Grab the most recent measuremets by 
float temp = getTemperature() ; calling the WeatherData’s getter meth— 
float humidity = getHumidity () ; ods (already implemented). 

float pressure = getPressure() ; 


currentConditionsDisplay.update (temp, humidity, pressure) ; Now update 
statisticsDisplay.update (temp, humidity, pressure) ; Lhe displays... 
forecastDisplay.update (temp, humidity, pressure) ; 
} 
spla element to 
// other WeatherData methods here Call each dis? Y assind, it the 
} update its display, F 
ost recent measuremen > 
vn 


Ge sharpen your pencil 
ere yer p 


Based on our first implementation, which of the following apply? 


(Choose all that apply.) 


LI A. We are coding to concrete LI D. The display elements don’t implement a 
implementations, not interfaces. common interface. 


LI B. For every new display element we need J E. We haven’t encapsulated the part that 
to alter code. changes. 


LJ C. We have no way to add (or remove) LJ FE Weare violating encapsulation of the 
display elements at run time. WeatherData class. 


Definition of SWAG: Scientific Wild A** Guess 


the observer pattern 
What's wrong with our implementation? 


Think back to all those Chapter 1 concepts and principles... 


public void measurementsChanged() { 


float temp = getTemperature () ; Resa oe change, we need 
float humidity = getHumidity () ; L exbapsilate this 
float pressure = getPressure() ; P 


statisticsDisplay.update(temp, humidity, pressure) ; 


urrentConditignsDisplay.update (temp, humidity, pressure) ; ) 
forecastDisplay/update (temp, humidity, pressure) ; 


a Sf 


At least we seem to be using a 
Common interface to talk to the 
display elements... they all have an 


By coding to tontrete implementations update() method takes the temp, 
we have no way to add or remove humidity, and pressure values. 
other display elements without making, 

changes to the program. 


Umm, I know I'm new 

here, but given that we are in 
the Observer Pattern chapter, 
maybe we should start using it? 


We'll take a look at 
Observer, then come 
back and figure out how 


to apply it to the weather 
monitoring app. 


meet the observer pattern 


Meet the Observer Pattern 


You know how newspaper or magazine 
subscriptions work: 


44 


@ A newspaper publisher goes into business and begins 
publishing newspapers. 


e You subscribe to a particular publisher, and every time 
there’s a new edition it gets delivered to you. As long as 
you remain a subscriber, you get new newspapers. 


@ You unsubscribe when you don’t want papers anymore, 
and they stop being delivered. 


4) While the publisher remains in business, people, hotels, 


airlines and other businesses constantly subscribe and 
unsubscribe to the newspaper. 


Miss what's going on 
in Objectville? No way, of 
course we subscribe! 


Chapter 2 


the observer pattern 


Publishers + Subscribers = Observer Pattern 


If you understand newspaper subscriptions, you pretty much 
understand the Observer Pattern, only we call the publisher 
the SUBJECT and the subscribers the OBSERVERS. 


Let’s take a closer look: 


The observers have subscribed to 
(registered with) the Subject 
to receive updates when the 
Subject’s data changes: 

When data in the Subject changes) ") 


the observers are notified. 


sett manages 


Subject ob wee a [ge 
et wea oe 


Yee of 
“‘bject oo 


New data values are 
communicated to the 
observers in some form 


N . Ho: 
(0) S 
when they change. use O° 


Observer Objects 


This ob\ ect isnt an 

4 N pees so it doesn £ 
cs get notified when the 

Puck ove Subject's data changes: 
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a day in the life of the observer pattern 


A. day in the life of the Observer Pattern 


A Duck object comes along 
and tells the Subject that 
it wants to become an 
observer. 


Duck really wants in on the 
action; those ints Subject is 
sending out whenever its state 
changes look pretty interesting... 


Observers 


The Duck object is now an 
official observer. 


Duck is psyched... he's on the 
list and is waiting with great 
anticipation for the next 
notification so he can get an int. 


Observers 


The Subject gets a new 
data value! 


Now Duck and all the rest of the 
observers get a notification that 
the Subject has changed. 


Observers 
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The Mouse object asks to be 
removed as an observer. 


The Mouse object has been 
getting ints for ages and is tired 
of it, so it decides it's time to 
stop being an observer. 


the observer pattern 


Observers 


Mouse is outta here! 


The Subject acknowledges the 
Mouse's request and removes it 
from the set of observers. 


[ Observers | 


The Subject has another 
new int. 


All the observers get another 
notification, except for the 
Mouse who is no longer included. 
Don't tell anyone, but the Mouse 
secretly misses those ints... 
maybe it'll ask to be an observer 
again some day. 


Observers 
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five minute 


Five minute drama: a subject for observation 


In today's skit, two post-bubble software developers 
encounter a real live head hunter... 


This is 
Ron, I'm looking for a 
Java development position, I've 
got five years experience and... 


Uh, yeah, 
you and everybody 
else, baby. I'm putting 
you on my list of Java 
developers, don't call me, 
T'll call you! 


Oo 
\ oe 


» 
("i 
j 


iy 


g 
y 
f 

\ 


i} 


v 


vv 


Headhunter/Subject 


Software 
Developer #1 


T'll add you to the list, 
you'll know along with 
everyone else. 


Hi, I'm Jill, I've 


written a lot of EJB . 
systems, I'm interested | 
in any job you've got with yy oh 
Java development. ba Owe 
j ry \ 
ny f 


Software 
Developer #2 


Subject 
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Meanwhile for Ron and Jill life goes on; 
if a Java job comes along, they'll get 
notified. After all, they are observers. 


Thanks, I'll 
send my resume 
right over. 


This guy is areal jerk, 
who needs him. I'm 
looking for my own job. 


Hey 
observers, 
there's a Java opening 
down at JavaBeans-R- 

Us, jump on it! Don't 
blow it! 


Bwahaha, money 
in the bank, baby! 


Observer 


Observer 


Subject 


Arghhhll! Mark my 
words Jill, you'll never work 
in this town again if I have 
anything to do with it. You're 
off my call list!!! 


Jill lands her own job! 


You can take me 
off your call list, I 
found my own job! 


Observer 9 ] Subject 


49 


the observer pattern 


Two weeks later... 


& 


bs 


Jill's loving life, and no longer an observer. 
She's also enjoying the nice fat signing 
bonus that she got because the company 
didn't have to pay a headhunter. 


But what has become of our dear Ron? We hear 
he's beating the headhunter at his own game. 

He's not only still an observer, he's got his own 
call list now, and he is notifying his own observers. 
Ron's a subject and an observer all in one. 
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The Observer Pattern defined 


When you're trying to picture the Observer Pattern, a newspaper 
subscription service with its publisher and subscribers is a good 
way to visualize the pattern. 


In the real world however, you'll typically see the Observer Pattern 
defined like this: 


The Observer Pattern defines a one-to-many 
dependency between objects so that when one 


object changes state, all of its dependents are 
notified and updated automatically. 


Let's relate this definition to how we've been talking about the 
pattern: 


ONE TO MANY RELATIONSHIP 


Object that = 


holds state 


_ int is rer 
“‘Bject oo” 


The subject and observers define the one-to-many relationship. 
The observers are dependent on the subject such that when the 
subject’s state changes, the observers get notified. Depending on 
the style of notification, the observer may also be updated with 
new values. 


As you'll discover, there are a few different ways to implement 
the Observer Pattern but most revolve around a class design that 
includes Subject and Observer interfaces. 


Let’s take a look... 


the observer pattern 


The Observer Pattern 


defines a one-to-many 
relationship between a set 
of objects. 


When the state of one 


object changes, all of its 
dependents are notitied. 


: 
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loose coupling 


The Observer Pattern defined: 


the class diagram All potential dbsevers need 


: he Observer 
o implement. terk 
ve nterxace 
interface. This tn () 
4 whe cher Each subject pat has one method oPdaLe 
1. Ke Suet iy kate Xp = tan have many That gets talled when the 
ees aks wse we to sca observer Gubject’s state Chande® 
Obvy¢' $ “ao, GOS 
ver ¢ 
< dose on WED ( 
wes 
ers Oo, nie observers <<interface>> 
ubject Observer 
registerObserver() update() 
removeObserver() 
notifyObservers() 


subject 


ConcreteSubject ConcreteObserver 


registerObserver() {...} 
removeObserver() {...} 


update() 


// other Observer specific 


A tonerete subject always 


implements the Subject notifyObservers() {...} methods 
interface In addition to getState() 
ister and remove setState() 
ies the conerete subject 
implements a notityObservers ere on ee 
method that is used te wpdave The contrete subject may 


any class that implements the 


all the current. observers have methods Lor setting and 


more avout Observer interface. Each observer 
whenever state Changes: getting, ts state (more registers with a Contrete subject 
fis later): to receive updates. 
thereyareno sg 
Dum uestions 


Q: What does this have to do with Q: How does dependence come 
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one-to-many relationships? 


A: With the Observer pattern, the 
Subject is the object that contains the 
state and controls it. So, there is ONE 
subject with state. The observers, on 
the other hand, use the state, even 

if they don’t own it. There are many 
observers and they rely on the Subject 
to tell them when its state changes. 

So there is a relationship between the 
ONE Subject to the MANY Observers. 


into this? 


A: Because the subject is the sole 
owner of that data, the observers are 
dependent on the subject to update 
them when the data changes. This 
leads to a cleaner OO design than 
allowing many objects to control the 
same data. 


the observer pattern 


The power of Loose Coupling 


When two objects are loosely coupled, they can interact, 
but have very little knowledge of each other. 


The Observer Pattern provides an object design where 
subjects and observers are loosely coupled. 


Why? 


The only thing the subject knows about an observer is that it 
implements a certain interface (the Observer interface). It doesn’t need to 
know the concrete class of the observer, what it does, or anything else about it. 


We can add new observers at any time. Because the only thing the subject 
depends on is a list of objects that implement the Observer interface, we can add new 


observers whenever we want. In fact, we can replace any observer at runtime with How man 
another observer and the subject will keep purring along. Likewise, we can remove Te erent kinds 
observers at any time. dime gt vee tan You 


We never need to modify the subject to add new types of observers. Let’s 7, identif Y here? 
say we have a new concrete class come along that needs to be an observer. We don’t 4) 

need to make any changes to the subject to accommodate the new class type, all 

we have to do is implement the Observer interface in the new class and register as 

an observer. The subject doesn’t care; it will deliver notifications to any object that 


implements the Observer interface. 


We can reuse subjects or observers independently of each other. If we 
have another use for a subject or an observer, we can easily reuse them because the 
two aren't tightly coupled. 


Changes to either the subject or an observer will not affect the other. 
Because the two are loosely coupled, we are free to make changes to either, as long as 
the objects still meet their obligations to implement the subject or observer interfaces. 


Design Principle 


Strive for loosely coupled designs 
between objects that interact. 


Loosely coupled designs allow us to build flexible OO 
systems that can handle change because they minimize 
the interdependency between objects. 
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planning the 


sharpen your pencil 
mee yer P 


Before moving on, try sketching out the classes you'll need to implement the 
Weather Station, including the WeatherData class and its display elements. 

Make sure your diagram shows how all the pieces fit together and also how 
another developer might implement her own display element. 


If you need a little help, read the next page; your teammates are already 
talking about how to design the Weather Station. 
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Cubicle conversation 


Back to the Weather Station project, your teammates have 
already started thinking through the problem... 


So, how are we 
going to build this thing? 


Mary: Well, it helps to know we’re using the Observer Pattern. 
Sue: Right... but how do we apply it? 


Mary: Hmm. Let’s look at the definition again: 


-_ The Observer Pattern defines a one-to-many dependency between objects so that when one 
; object changes state, all its dependents are notified and updated automatically. 


Mary: That actually makes some sense when you think about it. Our WeatherData 
class is the “one” and our “many” is the various display elements that use the weather 
measurements. 


Sue: That’s right. The WeatherData class certainly has state... that’s the temperature, 
humidity and barometric pressure, and those definitely change. 


Mary: Yup, and when those measurements change, we have to notify all the display 
elements so they can do whatever it is they are going to do with the measurements. 


Sue: Cool, I now think I see how the Observer Pattern can be applied to our Weather 
Station problem. 


Mary: There are still a few things to consider that I’m not sure I understand yet. 
Sue: Like what? 
Mary: For one thing, how do we get the weather measurements to the display elements? 


Sue: Well, looking back at the picture of the Observer Pattern, if we make the 
WeatherData object the subject, and the display elements the observers, then the 
displays will register themselves with the WeatherData object in order to get the 
information they want, right? 


Mary: Yes... and once the Weather Station knows about a display element, then it can 
just call a method to tell it about the measurements. 


Sue: We gotta remember that every display element can be different... so I think that’s 
where having a common interface comes in. Even though every component has a 
different type, they should all implement the same interface so that the WeatherData 
object will know how to send them the measurements. 


Mary: I see what you mean. So every display will have, say, an update() method that 
WeatherData will call. 


Sue: And update() is defined in a common interface that all the elements implement... 
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Designing the Weather Station 


How does this diagram compare with yours? 


Let's also create an interface 


mponents for all displa elements 
Later All 1 bee to cee The display 
guy =e ate This gives the elements just need to 
Heres al = eae 3 Common interface to implement a display() method. 
Ams snow ul 1 owes Lime 


<<interface>> observers 
Subject 


registerObserver() 


removeObserver() 
notifyObservers() 


Lalk to when * 
+ update the observers: ) 


<<interface>> <<interface>> 
Observer DisplayElement 


update() display() 


CurrentConditionsDisplay 


update() : aes ; 
: display() { // display current PUR ty DIS piel 
WeatherData measurements } update() 
registerObserver() display() {// display 
removeObserver() something else based on 
notifyObservers() measurements } 
This dj StatisticsDisplay 
neue Aa element. update() K 
getHumidity() e current display() { // display the aver- Developers 
sees medsurements fron the age, min and max measure- mol oak 
measurementsChanged() WeatherData object. ments } cane 
the Observer 
and Display 
interfaces to 
This one keeps track ForecastDisplay ate their own 
Data now : update() se 
Weathe sett of the min/ava/max display element: 
implements the Subject cnpaeuveentecacd display() {// display the ¥ 
interface: displays them. = 
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This display shows the weather 
hae a on the barometer: 


These three display elements should have a pointer to 


WeatherData labeled “subject” too, but boy would 
this diagram start to look like spaghetti if they did. 


the observer pattern 


Implementing the Weather Station 


We’re going to start our implementation using the class diagram and following Mary 
and Sue’s lead (from a few pages back). You'll see later in this chapter that Java 
provides some built-in support for the Observer pattern, however, we’re going to get 
our hands dirty and roll our own for now. While in some cases you can make use of 
Java’s built-in support, in a lot of cases it’s more flexible to build your own (and it’s 
not all that hard). So, let’s get started with the interfaces: 


Both of these methods take an 


public interface Subject { aa Observer as an argument; that is, the 
public void registerObserver (Observer o) ‘3 Observer to be registered or removed. 


public void removeObserver (Observer 0); 


public void notifyObservers(); 


This method is called to notify all observers 
when the Subject’s state has changed. 


The Observer interface is 
implemented by all observers, 


public interface Observer { 
public void update (float temp, float humidity, float pressure); 


} A T ‘a so they all have to implement 
These are the state values the Observers get from the updatel) method. Here 
the Subject when a weather measurement changes we're following Mary and 


Sue’s lead and passing the 
measurements to the observers. 


public interface DisplayElement { 
public void display(); N\ 
} The DisplayElement interface just in¢ludes one 
method, display, that we will call when the 
display element needs to be displayed. 


oe RAIN 
Mary and Sue thought that passing the measurements directly to the 
observers was the most straightforward method of updating state. Do 
you think this is wise? Hint: is this an area of the application that 


might change in the future? If it did change, would the change be well 
encapsulated, or would it require changes in many parts of the code? 


Can you think of other ways to approach the problem of passing the 
updated state to the observers? 


Don’t worry, we’ll come back to this design decision after we finish the 
initial implementation. 
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implementing the weather station 


Implementing the Subject interface in REMEMBER: we don't provide 


import and package statements in 


WeatherData the Code listings. Get the complete 


source code from the wickedlysmart 


Remember our first attempt at implementing the WeatherData class at the web site. You'll find the URL on 
beginning of the chapter? You might want to refresh your memory. Now page xxxiii in the Intro. 
it’s time to go back and do things with the Observer Pattern in mind... 


Here we implement the Subject Interface. 
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public class WeatherData implements Subject { &7 7 Weather Data now implements 


private ArrayList observers; the Subject interface. 
private float temperature; 

private float humidity; We've added an AwrayList to 
private float pressure; hold the Observers, and we 


eveate it in the eonstruttor- 
public WeatherData() { 


observers = new ArrayList (); 


When an observer registers, we just 


public void registerObserver (Observer 0) { & add it to the end of the list. 
observers.add(o) ; 


} 


Likewise, when an observer wants to un—register, 


ae we just take it off the list. 


public void removeObserver (Observer o) { 
int i = observers.indexOf(o); 


se Here’s the fun part; this is where we 
ep i eens tell all the observers about the state. 
Because they are all Observers, we 


: . 
know they all implement update(), so 
—_ we know how to notify them. 


public void notifyObservers() { 


for (int i = 0; i < observers.size(); i++) { 
Observer observer = (Observer) observers.get (i); 
observer.update (temperature, humidity, pressure); 
en 
} | We notify the Observers 
— we get updated aie’ 
public void measurementsChanged() { Crom the Weather 


notifyObservers (); 


} 


public void setMeasurements (float temperature, float humidity, float pressure) { 
this.temperature = temperature; 


one thiiey = Kuna Okay, while we wanted to ship a nite little 
Enheaprescute = preccure: é ~~ weather station with each book, the publisher 
measurement sChanged () ; wouldn't go for it. So, rather than reading 

; attual weather data off a device, we're goin 


to use this method to test our display elements. 
Or, for fun, you could write code to grab 
measurements off the web. 


// other WeatherData methods here 
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the observer pattern 


Now, let’s build those display elements 


Now that we’ve got our WeatherData class straightened out, it’s time to build the 
Display Elements. Weather-O-Rama ordered three: the current conditions display, the 
statistics display and the forecast display. Let’s take a look at the current conditions 
display; once you have a good feel for this display element, check out the statistics and 
forecast displays in the head first code directory. You'll see they are very similar. eg 
also im 


| : 
ample ut Cause Sie DisplayElement 
bie alent changes fro require all displa : omg to ; 
W ile 5 ka doje’ implement this A iil - 
e 


public class CurrentConditionsDisplay implements Observer, 
private float temperature; 
private float humidity; 
private Subject weatherData; 


DisplayElement { 


The constructor is passed the 
weatherData object (the Subject) 
and we use it to register the 
display as an observer. 


public CurrentConditionsDisplay (Subject weatherData) { 
this.weatherData = weatherData; 
weatherData.registerObserver (this); 


} 


public void update (float temperature, 
this.temperature = temperature; 


this.humidity = humidity; <™™, When update( is called, we 
display(); save the temp and humidity 


and tall display0. 


float humidity, float pressure) { 


} 


public void display() { 
System.out.printin(“Current conditions: “ + temperature 
+ “F degrees and “ + humidity + “% humidity”); The display) method 


| cust prints out the most 
st Prin 
| 7 ak temp and humidity. 


thereyareno 
Dumb Questions 


the way the data gets displayed. We 
are going to see this when we get to 


Q: Is update() the best place to 
call display? 


A: In this simple example it made 
sense to call display() when the values 
changed. However, you are right, 

there are much better ways to design 


the model-view-controller pattern. 


: Why did you store a reference 
to the Subject? It doesn’t look 
like you use it again after the 
constructor? 


A: True, but in the future we 
may want to un-register ourselves as 
an observer and it would be handy 
to already have a reference to the 
subject. 
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testing the weather station 


Power up the Weather Station 


1) First, let’s create a test harness 


The Weather Station is ready to go, all we need is some code to glue 
everything together. Here’s our first attempt. We’ll come back later in 
the book and make sure all the components are easily pluggable via a 
configuration file. For now here’s how it all works: 


Fst eveate 
WeatherDat@ 


er object 


public class WeatherStation { 


public static void main(String[] args) { 
WeatherData weatherData = new WeatherData(); 


the 


atherData); 


Create the three 
displays and 

pass them the 
WeatherData object. 


\f you don't 
want to download CurrentConditionsDisplay currentDisplay = 
the code, you new CurrentConditionsDisplay (weatherData) ; 
tan Comment ou StatisticsDisplay statisticsDisplay = new StatisticsDisplay (weatherData) ; 
these two lines ForecastDisplay forecastDisplay = new ForecastDisplay ( 
and vun it. 
weatherData.setMeasurements(80, 65, 30.4f); 
weatherData.setMeasurements (82, 70, 29.2f); 
weatherData.setMeasurements(78, 90, 29.2f); 
} Cimulate new weather 
} measurements. 


2) Run the code and let the Observer Pattern do its magic 


File Edit Window Help StormyWeather 

Sjava WeatherStation 

Current conditions: 80.0F degrees and 65.0% humidity 
Avg/Max/Min temperature = 80.0/80.0/80.0 

Forecast: Improving weather on the way! 

Current conditions: 82.0F degrees and 70.0% humidity 


Avg/Max/Min temperature = 81.0/82.0/80.0 

Forecast: Watch out for cooler, rainy weather 
Current conditions: 78.0F degrees and 90.0% humidity 
Avg/Max/Min temperature = 80.0/82.0/78.0 

Forecast: More of the same 


% 
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were your pencil 


Johnny Hurricane, Weather-O-Rama’s CEO just called, they can’t possibly ship without a Heat Index 
display element. Here are the details: 


The heat index is an index that combines temperature and humidity to determine the apparent 
temperature (how hot is actually feels). To compute the heat index, you take the temperature, T, and the 
relative humidity, RH, and use this formula: 


heatindex = 


16.923 + 1.85212 * 107 * T + 5.37941 * RH - 1.00254 * 107 * T 
* RH + 9.41695 * 10° * T? + 7.28898 * 10° * RH? + 3.45372 * 10% 
* 7? * RH - 8.14971 * 104 * T * RH? + 1.02102 * 105 * T? * RH? - 
3.8646 * 10° * T? + 2.91583 * 10° * RH? + 1.42721 * 10° * T° * RH 
+ 1.97483 * 107 * T * RH? - 2.18429 * 10% * T? * RH? + 8.43296 * 
107° * T? * RH? - 4.81975 * 10°? * 3 * RH? 


So get typing! 


Just kidding. Don’t worry, you won't have to type that formula in; just create your own HeatIndexDisplay. 
java file and copy the formula from heatindex.txt into it. 


Re You can get heatindex.txt from wickedlysmart.com 


How does it work? You'd have to refer to Head First Meteorology, or try asking someone at the National 
Weather Service (or try a Google search). 


When you finish, your output should look like this: 


| File Edit_Window Help OverdaRainbow 
Sjava WeatherStation 

Current conditions: 80.0F degrees and 65.0% humidity 
Avg/Max/Min temperature = 80.0/80.0/80.0 

Forecast: Improving weather on the way! 

Heat index is 82.95535 

Current conditions: 82.0F degrees and 70.0% humidity 
Avg/Max/Min temperature = 81.0/82.0/80.0 


Forecast: Watch out for cooler, rainy weather 
Heat index is 86.90124 


Current conditions: 78.0F degrees and 90.0% humidity 
Avg/Max/Min temperature = 80.0/82.0/78.0 

Forecast: More of the same 

Heat index is 83.64967 


% 
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fireside chat: subject and observer 


Fireside Chats 
a ; 
ae. 


Subject 


I’m glad we’re finally getting a chance to chat in 
person. 


Well, I do my job, don’t I? I always tell you what’s 


going on... Just because I don’t really know who 


you are doesn’t mean I don’t care. And besides, I 


do know the most important thing about you— 
you implement the Observer interface. 


Oh yeah, like what? 


Well excuuuse me. I have to send my state with my 


notifications so all you lazy Observers will know 
what happened! 


Well... I guess that might work. [’d have to open 


myself up even more though to let all you Observers 
come in and get the state that you need. That might 
be kind of dangerous. I can’t let you come in and 


just snoop around looking at everything I’ve got. 
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Tonight's talk: A Subject and Observer spar over the right 
way to get state information to the Observer. 


Observer 


Really? I thought you didn’t care much about 
us Observers. 


Well yeah, but that’s just a small part of who I 
am. Anyway, I know a lot more about you... 


Well, you’re always passing your state around 
to us Observers so we can see what’s going 
on inside you. Which gets a little annoying at 
times... 


Ok, wait just a minute here; first, we’re not lazy, 
we just have other stuff to do in between your 
oh-so-important notifications, Mr. Subject, and 
second, why don’t you let us come to you for 
the state we want rather than pushing it out to 
just everyone? 


Subject 


Yes, I could let you pull my state. But won’t that be 
less convenient for you? If you have to come to me 
every time you want something, you might have to 
make multiple method calls to get all the state you 
want. ‘That’s why I like push better... then you have 
everything you need in one notification. 


Well, I can see the advantages to doing it both ways. 
I have noticed that there is a built-in Java Observer 
Pattern that allows you to use either push or pull. 


Great... maybe I'll get to see a good example of 
pull and change my mind. 


the observer pattern 


Observer 


Why don’t you just write some public getter 
methods that will let us pull out the state we 
need? 


Don’t be so pushy! ‘There’s so many different 
kinds of us Observers, there’s no way you can 
anticipate everything we need. Just let us come 
to you to get the state we need. That way, if 
some of us only need a little bit of state, we 
aren't forced to get it all. It also makes things 
easier to modify later. Say, for example, you 
expand yourself and add some more state, well 
if you use pull, you don’t have to go around 
and change the update calls on every observer, 
you just need to change yourself to allow more 
getter methods to access our additional state. 


Oh really? I think we’re going to look at that 
next.... 


What, us agree on something? I guess there’s 
always hope. 


java’s built-in observer pattern 


Using Java's built-in 
Observer Pattern 


So far we’ve rolled our own code for the 
Observer Pattern, but Java has built-in support 
in several of its APIs. ‘The most general is the 
Observer interface and the Observable class in 
the java.util package. These are quite similar 

to our Subject and Observer interface, but give 
you a lot of functionality out of the box. You 
can also implement either a push or pull style of 
update to your observers, as you will see. 


To get a high level feel for java.util. Observer and 
java.util.Observable, check out this reworked 
OO design for the WeatherStation: 


keeps 

No: ervable class 

ae "f all your observers 
and notiries them for you 


Observable observers 
Observable is a addObserver() 
CLASS not an deleteObserver() 
interface, so notifyObservers() 
WeatherData sotcnanded) subject 
extends Observable. 


WeatherData 
1} \oot getTemperature() 
ys 406° getHumidity() 
% * sat! en ko getPressure() 
; Wnts a 
oe “ “ ' hich we Can 
e Here's our Subject, whi ! 
now also Call the Observable. We 
don't need the vegister(), remove! 
and notifyObservers() methods 
anymore) We inherit that behavior 
Som the superclass: 
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With Java's built-in 
support, all you have to do is 
extend Observable and tell it 
when to notify the Observers. 
The API does the rest for you. 


is should look familiar: In 
hare ¢ exactly the same as 
ur previous class diagram. ieiteatehe 
° ) DisplayElement 
interface, but all 
the displays still 
implement it too. 


A 


<<interface>> 
Observer 


update() 


GeneralDisplay StatisticsDisplay ForecastDisplay 
update() update() update() 
display() display() display() 


a 
to make to the updatel? 
but basically its 


bserver interxace, 


(C method that’s called by the Subject: 


There will be a few changes 
method in the tontrete Observers, 
the same idea. we have a Common 9) 


with an update 


the observer pattern 


How Java's built-in Observer Pattern works 


The built in Observer Pattern works a bit differently than the implementation that we used 
on the Weather Station. The most obvious difference is that WeatherData (our subject) 
now extends the Observable class and inherits the add, delete and notify Observer methods 
(among a few others). Here’s how we use Java’s version: 


For an Object to become an observer... 


As usual, implement the Observer interface (this time the java.util. Observer 
interface) and call addObserver() on any Observable object. Likewise, to remove 
yourself as an observer just call deleteObserver(). 


For the Observable to send notifications... 


First of all you need to be Observable by extending the java.util.Observable 
superclass. From there it is a two step process: 


1) You first must call the setChanged() method to signify 
that the state has changed in your object 


This aan vee cae 
ett 
arbitrary data a ri 
© Then, call one of two notifyObservers() methods: bat gets Passee 
each Observer when | 
; fied 
either notifyObservers() OF notifyObservers (Object arg) ‘s rotiie 


For an Observer to receive notifications... 


It implements the update method, as before, but the signature of the P : 
method is a bit different: data object 
update (Observable o, Object arg) 
7 

The Subject that sent 

the iithestion | is passed This will be the data object that was 

nas this argumen . passed to notif Observers(), or null if 

a data object wasn ’£ specified. 


If you want to “push” data to the observers you can pass the data as a data object 
to the notifyObservers(arg) method. If not, then the Observer has to “pull” the data 
it wants from the Observable object passed to it. How? Let’s rework the Weather 
Station and you'll see. 


behind the scenes 


Wait, before we get 
to that, why do we need this 
setChanged() method? We didn't 
need that before. 


The setChanged() method 1s used to signify that the state has changed and that notifyObservers(), 
when it is called, should update its observers. If notifyObservers() is called without first calling 
setChanged(), the observers will NOT be notified. Let’s take a look behind the scenes of 
Observable to see how this works: 


—— Behind 


the Scenes 
setChanged() { The setChanged() method sets 
changed = true a changed flao, to true. 
} a 
a , | 0 onl 
o notifyObservers(Object arg) { notif Observers Y 
« Ce* if (changed) { ET votifies its observers if the 
for every observer on the list { changed flag, is TRUE. 
call update (this, arg) 
Tatees = false And after it notifies the 
} Ss. observers, it sets the 
} changed flag back to false. 
notifyObservers() { 
notifyObservers(null) 
} 


Why is this necessary? ‘The setChanged() method 1s meant to give you more flexibility in how 
you update observers by allowing you to optimize the notifications. For example, in our weather 
station, imagine if our measurements were so sensitive that the temperature readings were 
constantly fluctuating by a few tenths of a degree. That might cause the WeatherData object 
to send out notifications constantly. Instead, we might want to send out notifications only if the 
temperature changes more than half a degree and we could call setChanged() only after that 
happened. 


You might not use this functionality very often, but it’s there if you need it. In either case, you 
need to call setChanged() for notifications to work. If this functionality is something that is useful 
to you, you may also want to use the clearChanged() method, which sets the changed state back to 
false, and the hasChanged() method, which tells you the current state of the changed flag. 
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Reworking the Weather Station with the built-in support 


First, let’s rework WeatherData to use 
java.util.Observable 


(1) Make sure we are importing the e 


tight, Observer/ Observable. e We don't need to keep track of 


We are now our observers anymore, or manage 
sub¢lassing Observable. their registration and removal, 
(the superclass will handle that) 
) 
v v 
import java.util.Observable; ia wi : eae oe for 
import java.util.Observer; MEDI SUeLy Sa MELE: 


public class WeatherData extends Observable { i l 
private float temperature; Our constructor no longer 


private float humidity; needs to create a data 
private float pressure; structure to hold Observers. 


Dobe Ciena nace) ee Notice we aren't sending a data object with 
the notifyObservers() call. That means we're 


public void measurementsChanged() { : 
setChanged() ; * using the PULL model. 
notifyObservers (); 


public void setMeasurements (float temperature, float/humidity, float pressure) { 


this.temperature = temperature; 
this.humidity = humidity; 
this.pressure = pressure; We now first call setChanged() to 
measurementsChanged () ; indicate the state has changed 
} before calling, notifyObservers(). 


public float getTemperature() { 
return temperature; 


} 


public float getHumidity() { 


return humidity; \ 
ees © These methods aren't new, but 


W ” 
i because we are going to use “pull 
public float getPressure() { Cc ae thought st leaning you 
YeCUrn pressure; 


} they are here. The Observers 
} will use them to get at the 
WeatherData object's state. 
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current conditions rework 


Now, let’s rework the CurrentConditionsDisplay 


1) Again, make sure we are importing, 
the right Observer/ Observable. 


e We now are implementing the Observer interface from java.util. 


import java.util.Observable; 
import java.util.Observer; 


public class CurrentConditionsDisplay implements Observer, DisplayElement { 
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Observable observable; 
Our constructor now takes an 


ivate float t te ; 
ee ey ee eee aa 3S | Observable and we use this to 


private float humidity; . 
add the current Conditions 


public CurrentConditionsDisplay (Observable observable) { object as an Observer. 
this.observable = observable; 
observable.addObserver (this) ; 


We've changed the 


public void update (Observable obs, Object arg) { Fg 4) update() method 


if (obs instanceof WeatherData) { to take both an 
WeatherData weatherData = (WeatherData) obs; Observable and dh 
this.temperature = weatherData.getTemperature () ; opti ld re € 
this. humidity = weatherData.getHumidity(); feonal da argument. 
display(); 
} 
} 
public void display() { In update(), we first 
System.out.printin(“Current conditions: “ + temperature 5) make sure the observable 
+ “F degrees and + humidity + “S humidity”); ie of type WeatherData 
and then we use its 


getter methods to 
obtain the temperature 
and humidity 
measurements. After 
that we call displayQ. 
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Code Magnets 


The ForecastDisplay class is all scrambled up on the fridge. Can you 
reconstruct the code snippets to make it work? Some of the curly 
braces fell on the floor and they were too small to pick up, so feel 
free to add as many of those as you need 


observable .addObserver (this); 


if (observable instanceof WeatherData) { 


public class ForecastDisplay implements 
Observer, DisplayElement { 


i id display 0 { 
plic void 
- // display code here 


WeatherData weatherData = 
(WeatherData) observable: 


( r 
public void update Observable observable 


Object arg) | 


import java.util.Observable; 


import java.util.Observer; 
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test drive 


Running the new code 


Just to be sure, let’s run the new code... 


File Edit Window Help TryTihisAtHome 


Sjava WeatherStation 

Forecast: Improving weather on the way! 

Avg/Max/Min temperature = 80.0/80.0/80.0 

Current conditions: 80.0F degrees and 65.0% humidity 
Forecast: Watch out for cooler, rainy weather 
Avg/Max/Min temperature = 81.0/82.0/80.0 


Current conditions: 82.0F degrees and 70.0% humidity 
Forecast: More of the same 

Avg/Max/Min temperature = 80.0/82.0/78.0 

Current conditions: 78.0F degrees and 90.0% humidity 


% 


Hmm, do you notice anything different? Look again... 


You'll see all the same calculations, but mysteriously, the order of the text output 1s 
different. Why might this happen? Think for a minute before reading on... 


Never depend on order of evaluation of the 
Observer notifications 


The java.util.Observable has implemented its notifyObservers() method such that the 
Observers are notified in a different order than our own implementation. Who’s right? 
Neither; we just chose to implement things in different ways. 


What would be incorrect, however, is if we wrote our code to depend on a specific 
notification order. Why? Because if you need to change Observable/Observer 
implementations, the order of notification could change and your application would 
produce incorrect results. Now that’s definitely not what we’d consider loosely coupled. 
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Doesn't 
java.util.Observable 
violate our OO design principle 
of programming to interfaces 
not implementations? 


The dark side of java.util.Observable 


Yes, good catch. As you've noticed, Observable is a class, not an interface, and worse, 

it doesn’t even wmplement an interface. Unfortunately, the java.util.Observable 
implementation has a number of problems that limit its usefulness and reuse. That’s not 
to say it doesn’t provide some utility, but there are some large potholes to watch out for. 


Observable is a class 


You already know from our principles this is a bad idea, but what harm does it really 
cause? 


First, because Observable 1s a class, you have to subclass it. That means you can’t add 
on the Observable behavior to an existing class that already extends another superclass. 
This limits its reuse potential (and isn’t that why we are using patterns in the first place?). 


Second, because there isn’t an Observable interface, you can’t even create your own 
implementation that plays well with Java’s built-in Observer API. Nor do you have 
the option of swapping out the java.util implementation for another (say, a new, multi- 
threaded implementation). 


Observable protects crucial methods 


If you look at the Observable API, the setChanged() method is protected. So what? Well, 
this means you can’t call setChanged() unless you’ve subclassed Observable. This means 
you can’t even create an instance of the Observable class and compose it with your own 
objects, you have to subclass. The design violates a second design principle here. . .favor 
composition over inheritance. 


What to do? 


Observable may serve your needs if you can extend java.util.Observable. On the other 
hand, you may need to roll your own implementation as we did at the beginning of the 
chapter. In either case, you know the Observer Pattern well and you’re in a good position 
to work with any API that makes use of the pattern. 


observer and swing 


Other places you'll find the Observer Pattern 
inthe JOK 


The java.util implementation of Observer/Observable is not the only place you'll 
find the Observer Pattern in the JDK; both JavaBeans and Swing also provide their 
own implementations of the pattern. At this point you understand enough about 
observer to explore these APIs on your own; however, let’s do a quick, simple Swing 
example just for the fun of it. 


A little background... 


Let’s take a look at a simple part of the Swing API, the JButton. If you look under 
the hood at JButton’s superclass, AbstractButton, you'll see that it has a lot of add/ 
remove listener methods. These methods allow you to add and remove observers, 
or as they are called in Swing, listeners, to listen for various types of events that 
occur on the Swing component. For instance, an ActionListener lets you “listen in” 
on any types of actions that might occur on a button, like a button press. You’ll find 
various types of listeners all over the Swing API. 


A little life-changing application 


Okay, our application 1s pretty simple. You’ve got a button that says “Should I do 
it?” and when you click on that button the listeners (observers) get to answer the 
question in any way they want. We’re implementing two such listeners, called the 
AngelListener and the DevilListener. Here’s how the application behaves: 


- 
Here's our faney interfae: 


ove Curious about 
i Observer Pattern in 
JavaBeans check out the 
PropertyChangeListener 
interface: 


Should | do it? 
And here's the output when 
we click on the button. 

Ellesedie Wane eip HeMade S57 
java SwingObserverExample 
Devil answer 


Come on, do it! 


Angel Pegg Don’t do it, you might regret it! 
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And the code... 


This life-changing application requires very little code. All we need to do is 
create a JButton object, add it to a JFrame and set up our listeners. We’re going 
to use inner classes for the listeners, which is a common technique in Swing 
programming. If you aren’t up on inner classes or Swing you might want to 
review the “Getting GUI” chapter of Head First Java. 


plication that 


came and 


Simyle Swing, ap 
wust creates a trame 
eons a button nm it. 


public class SwingObserverExample { 
JFrame frame; 


public static void main(String[] args) { 
SwingObserverExampl xample = new SwingObserverExample(); 
example.go(); 


public void go() { 
frame = new JFrame(); 


Makes the devil and angel 
objects listeners (observ— 
JButton button = new JButton(“Should I do it?”); ers) of the button. 
button.addActionListener (new AngelListener()); 

button.addActionListener (new DevilListener()); 
frame.getContentPane().add(BorderLayout.CENTER, button) ; 

// Set frame properties her 


class AngelListener implements ActionListener { 
public void actionPerformed(ActionEvent event) { 
System.out.printlin(“Don’t do it, you might regret it!”); 


Here 
ar 
} idl elass definitions f 
ers, d r 
class DevilListener implements ActionListener { Classes (but ihe ctined 9S inner 
public void actionPerformed(ActionEvent event) { , don t have to be) 


System.out.println(“Come on, do it!”); 


a Rather than update(), the 
actionPerformed() method 
gets called when the state 
in the subject (in this case 
the button) changes. 
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your design toolbox 


® Tools for your Design Toolbox 


Welcome to the end of Chapter 2. 
You’ve added a few new things to your 
OO toolbox... 


00 Basies 


Noster action 


OO Principles 


ste what varies: 


Encapsyl 
Favor composition over 
anhevitance- \ 
1 es, 
er : : _ | Here's your newest 
ntacions inciple- Rememb é&; 
ynpleme ‘. - 


ley wa ible and 


much more en 
vesilient to change- 


loosely coupled 


pyeets that 


00 Patterns 


—ma 
Shred Observer - defines a ae ee 
entat dency between abje ie lo all rts 
inter, devant” Spyett Chanaes A sated 
vary | nen? € notified 3m . 
Y “egendents a 
sutomatically 
— 


A new pattern for Communicating, state to a 

set of objects ina loosely coupled manner. We 
haven't seen the last of the Observer Pattern — 
just wait until we talk about MVC! 


74 Chapter 2 


-— BULLET POINTS — 


The Observer Pattern defines 
a one-to-many relationship 
between objects. 


Subjects, or as we also know 
them, Observables, update 
Observers using a common 
interface. 


Observers are loosely coupled 
in that the Observable knows 
nothing about them, other 
than that they implement the 
Observer Interface. 


You can push or pull data from 
the Observable when using 
the pattern (pull is considered 
more “correct’). 


Don’t depend on a specific 
order of notification for your 
Observers. 


Java has several 
implementations of the 
Observer Pattern, including 
the general purpose java.util. 
Observable. 


Watch out for issues with 
the java.util.Observable 
implementation. 


Don't be afraid to create 
your own Observable 
implementation if needed. 


Swing makes heavy use of the 
Observer Pattern, as do many 
GUI frameworks. 


You'll also find the pattern in 
many other places, including 
JavaBeans and RMI. 


the observer pattern 


Design Principle Challenge 


For each design principle, describe how the Observer Pattern 
makes use of the principle. 


Design Principle 


Identify the aspects of your application that vary 
and separate them from what stays the same. 


Design Principle 


Program to an interface, not an implementation. 


This is a hard one, hint: think about how observers 
and subjects work together. 


Design Principle 


Favor composition over inheritance. 
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crossword puzzle 
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aaa 


Time to give your right brain something to do again! 
This time all of the solution words are from chapter 2. 


PET 


| 


a 


= 


rd 


Across 

1. Observable is a not an interface 
3. Devil and Angel are to the button 
4. Implement this method to get notified 

5. Jill got one of her own 

6. CurrentConditionsDisplay implements this 
interface 

8. How to get yourself off the Observer list 

12. You forgot this if you're not getting notified 
when you think you should be 

15. One Subject likes to talk to observers 
18. Don't count on this for notification 

19. Temperature, humidity and 

20. Observers are on the Subject 
21. Program to an not an 
implementation 

22. A Subject is similar to a 
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a 


Down 
2. Ron was both an Observer and a 
3. You want to keep your coupling 
7. He says you should go for it 

; can manage your observers for you 
10. Java framework with lots of Observers 
11. Weather-O-Rama's CEO named after this 
kind of storm 


13. Observers like to be when 
something new happens 
14. The WeatherData class the 


Subject interface 

16. He didn't want any more ints, so he removed 
himself 

17. CEO almost forgot the index display 
19. Subject initially wanted to__alll the data 
to Observer 


the observer pattern 


E e @eSharpen your pencil 
xePreise N 

Based on our first implementation, which of the following apply? 
solutions 


(Choose all that apply.) 


MW A. We are coding to concrete {] D. The display elements don’t implement a 
implementations, not interfaces. common interface. 


MB. For every new display element we need WM E. We haven't encapsulated what changes. 
to alter code. 


yw C. We have no way to add display Q) EF Weare violating encapsulation of the 
elements at run time. WeatherData class. 


Design 
rinciple 


ad Challenge 


The thing that varies in the Observer Pattern 


is the state of the Subject and the number and 


Design Principle types of Observers. With this pattern, you éan 
Identify the aspects of your application that 3 

Ger cri separate HE ai OnDU RET enVe Wie vary the objects that are dependent on the state 
same. of the Subject, without having, to change that 


Subject. That's called planning ahead! 


Both the Subject and Observer use interfaces. 


The Subject keeps track of objects implement— 
Design Principle ing the Observer interface, while the observers 


Program to an interface, not an implementation. register with, and get notified by, the Subject 


interface. As we've seen, this keeps things nie 


and loosely coupled. 


The Observer Pattern uses composition to Com— 


pose_any number of Observers with their Subjects. 


PESO auld) These relationships aren't set up by some kind of 


Favor composition over inheritance. 


inheritance hierarchy. No, they are set up at run— 


time by Composition! 
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exercise solutions 


Code Magnets 


Exereise 


import Java.util.Observable; 


import java.util.Observer; 
uti 
public class ForecastDisplay implements So 1on$§ 
Observer, DisplayElement { 
Beeie«, 


: rrentPr 
Private float Madeeecee = 29.928; 
e; . 


isplay (Observable 


public ForecastD 
observable) { 


oe weatherData = 
eatherData) observable 


7 


observable. addObserver (they 


ible observable, 


(Observal 


public void update 
opject arg) { 


Ei 


if (observable instanceof WeatherData) { 


lastPressure = currentPressure; 
currentPressure = weatherData.getPressure(); 


a =a 


oid display 0 { 
// display code here 


pe} Li ALS (s. Pelits |r jeiui ii nye | 
Eon 
fo leis lejeiviele 
qd 


mo |v /e lols |s)eleiv ele 


BORO of oo 
1 
oO MANY. 


a 
Feel el cl 


) 
Gi 
[| 
¢ | 


A Go G ‘ wiafont 

A R 
gaoooodod ao ae 
Gi Ss rt | 


T 
Pijwirjejelrlalele Me My juje lil ils [ej ele 
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3 the Decorator Pattern 


= 
+ Decorating Objects * 


T used to think real men 
subclassed everything. That was 
until I learned the power of 
extension at runtime, rather than 
at compile time. Now look at me! 


Just call this chapter “Design Eye for the Inheritance Guy.” 
We'll re-examine the typical overuse of inheritance and you'll learn how to decorate 
your classes at runtime using a form of object composition. Why? Once you know the 
techniques of decorating, you'll be able to give your (or someone else’s) objects new 


responsibilities without making any code changes to the underlying classes. 
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the starbuzz story 


Welcome to Starbuzz Coffee 


Starbuzz Coffee has made a name for itself as the 
fastest growing coffee shop around. If you’ve seen one 


on your local corner, look across the street; you’ll see 
another one. 


Because they’ve grown so quickly, they’re scrambling 
to update their ordering systems to match their 
beverage offerings. 


When they first went into business they designed their 
classes like this... 


1 lass, 
goe is an abstract ¢ 
aie by all beverages 
offered in the coffee shor- 


Beverage The deseription instance | 
ms is set in each subtlass and holds a 
description descrip bien al the beverage, like 
The cost() method is getDescription() “Most Excellent Dark Roast - 
ene reres i a The getDeseription(? method 
nee an eee 
own implementation. // Other useful methods... returns the destription 
HouseBlend DarkRoast Decaf Espresso 


cost() 


| ( / 


Each subclass implements cost() to return the cost of the beverage. 
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In addition to your coffee, you can also ask for several condiments like 
steamed milk, soy, and mocha (otherwise known as chocolate), and have 
it all topped off with whipped milk. Starbuzz charges a bit for each of 
these, so they really need to get them built into their order system. 


Here’s their first attempt... 


Beverage 


description 


getDescription() 
cost() 


// Other useful methods... 


EspressoWithSteamedMilk 


agape eect sabe aee Hieasaaa DecafWithSteamedMilk andMocha 
HouseBle! andMocha cost() 
cost() cost() cost() 
cost() Espresso! leamet 
DarkRoastWithSteamedMilk Depaerncesurent andbaramel 
cost e pdCaraindl : andCaramel cost()) EspressoWithWhipandMocha 
Hou! 7 
HouseBiel cost”) DarkRoastwithw °St) DecafWith| 
cost} 
HouseBlendWii cost() 
| and§ cost() DarkRoastwil °°") Decal cost(| 
cost() TIOUSEDTENUY cost( es DecafWithSoy 
5 7 DecafWithSteamedMilk 
HouseBlendWith DarkRoastWithSteamedMilk 
{— .| andSoy ang EspressoWith 
HouseBlendWithWhip —~ keene DecafWithSteamedMilk 
LF esto DarkRoastWithSteamedM DarkRoa: ‘ cost() DecafWithSoyandMocha 
HouseBl cost) oat Decq 
— | cost() 
HouseBlendWithWhipandSoy 


EspressoWithSteamedMilk 
andWhip 


DecafWithSteamet 
a 


DarkRoastWithSteamedMilk 
i EspressoWithWhipandSoy 


DarkRoastWithWhipandSoy DecafWithWhipandSoy 


Whoa! 
Can you say 
“class explosion?” 


the 

h cost method computes 

ie of the coffee along, with the 
other tondiments in the ordev- 
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violating design principles 


oe RAI 
PQWER 
It’s pretty obvious that Starbuzz has created a maintenance nightmare for 


themselves. What happens when the price of milk goes up? What do they do 
when they add a new caramel topping? 


Thinking beyond the maintenance problem, which of the design principles that 
we’ve covered so far are they violating? 


jAem Big e ul Way) Jo OM] Buljejoin a4,A9yj] :JUIH 


This is stupid; why do we need 
all these classes? Can't we just use 
instance variables and inheritance in 
the superclass to keep track of the 
condiments? 


Well, let's give ita try. Let's start with the Beverage base 
class and add instance variables to represent whether or 
not each beverage has milk, soy, mocha and whip... 


Beverage 


description New boolean values for 


milk eath Condiment. 

soy 

mocha 

ull Now we'll implement. cost() in Beverage (instead of 
getDescription() keeping it abstract), so that it can caleulate the 
cost() tosts assotiated with the Condiments for a particular 


beverage instance. Subelasses will still override 


Si cost(), but they will also invoke the super version so 
hasSoy() that they can caleulate the total cost of the basic 
soi) beverage plus the costs of the added condiments. 
hasMocha() 

setMocha() 

hasWhip() These get and set the ae 

setWhip() caluas ‘ the tondimen : 


// Other useful methods.. 
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Now let's add in the subclasses, one 
for each beverage on the menu: 


r late the 
lass cost) will ealeu 
Pay eeiel the tondiments, while 


the decorator pattern 


Beverage 


description 
milk 

soy 

mocha 
whip 


getDescription() 


the overridden cost() in the subclasses 7? cost() 
¢ overvi 


will extend that fLunetionality to 


hasMilk() 
eifie {Milk 
sntlude costs for that spect el i 
beverage type: be setSoy() 
 cost() method needs to ComPu hasMocha() 
£ the beverage and then setMocha() 
the tost o ling the hasWhip() 
add in the ue by cal 0 setWhip() 
: im jon Ce 
superclass as // Other useful methods.. 
HouseBlend DarkRoast Decaf Espresso 
cost() cost() cost() 


G harpen our pencil 
4 y 


public class Beverage { 
public double cost() { 


Write the cost() methods for the following classes (pseudo-Java is okay): 


public class DarkRoast extends Beverage { 


public DarkRoast() { 
description = “Most Excellent Dark Roast"; 


public double cost() { 


you are here > 83 


impact of change 


See, five 
classes total. This is 
definitely the way to go. 


Ge sharpen your pencil 
eepeyer 


I'm not so sure; I can 
see some potential problems 
with this approach by thinking 
about how the design might need 
to change in the future. 


What requirements or other factors might change that will impact this design? 


Prige changes for condiments will force us to alter existing, Code. 


New condiments will force us to add new methods and alter the cost method in the superclass. 


We may have new beverages. For some of these beverages (iced tea?), the condiments 
may not be appropriate, yet the Tea subélass will still inherit methods like hasWhip(). 


What if a customer wants a double mocha? 


Your Lun 
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Master and Student... 


#™ Master: Grasshopper, it has been some time since our last 
meeting. Have you been deep in meditation on inheritance? 


_ Student: Yes, Master. While inheritance is powertul, | have 
learned that it doesn’t always lead to the most flexible or 
maintainable designs. 


Master: Ah yes, you have made some progress. So, tell me my student, how 
then will you achieve reuse if not through inheritance? 


Student: Master, | have learned there are ways of “inheriting” behavior at 
runtime through composition and delegation. 


Master: Please, go on... 


Student: When | inherit behavior by subclassing, that behavior is set statically 
at compile time. In addition, all subclasses must inherit the same behavior. If 
however, | can extend an object’s behavior through composition, then | can do 
this dynamically at runtime. 


Master: Very good, Grasshopper, you are beginning to see the power of 
composition. 


Student: Yes, it is possible for me to add multiple new responsibilities to objects 
through this technique, including responsibilities that were not even thought of 
by the designer of the superclass. And, | don’t have to touch their code! 


Master: What have you learned about the effect of composition on maintaining 
your code? 


Student: Well, that is what | was getting at. By dynamically composing objects, 
| can add new functionality by writing new code rather than altering existing 
code. Because I’m not changing existing code, the chances of introducing bugs 
or causing unintended side effects in pre-existing code are much reduced. 


Master: Very good. Enough for today, Grasshopper. | would like for you to 
go and meditate further on this topic... Remember, code should be closed (to 
change) like the lotus flower in the evening, yet open (to extension) like the 
lotus flower in the morning. 


the open-closed principle 


The Open-Closed Principle 


Grasshopper is on to one of the most important design principles: 


Design Principle 


Classes should be open 
for extension, but closed for 
modification. 


Come on ins we're CLOSED 


SVE 
open. Feel free to extend BUSINESS HouRs. 
our classes with any new behavior you Mon MB 1. P| 
like. If your needs or requirements change (and we ve EY 


know they will), just go ahead and make your own Wed IM 
extensions. 


Sorry, we’re closed. 
That’s right, we 
spent a lot of time getting 


this code correct and bug free, so we can’t let you 
alter the existing code. It must remain closed to 
modification. If you don’t like it, you can speak to 
the manager. 


Our goal is to allow classes to be easily extended to 
incorporate new behavior without modifying existing code. 
What do we get if we accomplish this? Designs that are 
resilient to change and flexible enough to take on new 
functionality to meet changing requirements. 
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th G 
bum > Questions 


Q: Open for extension and closed 
for modification? That sounds very 
contradictory. How can a design be 
both? 


A: That's a very good question. It 
certainly sounds contradictory at first. 


After all, the less modifiable something 
is, the harder it is to extend, right? 


As it turns out, though, there are some 
clever OO techniques for allowing 
systems to be extended, even if we can't 
change the underlying code. Think 
about the Observer Pattern (in Chapter 
2)... by adding new Observers, we can 
extend the Subject at any time, without 
adding code to the Subject. You'll see 
quite a few more ways of extending 
behavior with other OO design 
techniques. 


Q: Okay, | understand Observable, 
but how do | generally design 
something to be extensible, yet closed 
for modification? 


A: Many of the patterns give us 
time tested designs that protect your 


code from being modified by supplying 
a means of extension. In this chapter 
you'll see a good example of using the 
Decorator pattern to follow the Open- 
Closed principle. 


Q: How can | make every part of 
my design follow the Open-Closed 
Principle? 


the decorator pattern 


A: Usually, you can’t. Making OO 
design flexible and open to extension 


without the modification of existing 
code takes time and effort. In general, 
we don't have the luxury of tying down 
every part of our designs (and it would 
probably be wasteful). Following 

the Open-Closed Principle usually 
introduces new levels of abstraction, 
which adds complexity to our code. You 
want to concentrate on those areas that 
are most likely to change in your designs 
and apply the principles there. 


Q: How do I know which areas of 
change are more important? 


A: That is partly a matter of 
experience in designing OO systems and 


also a matter of knowing the domain 
you are working in. Looking at other 
examples will help you learn to identify 
areas of change in your own designs. 


While it may seem like a contradiction, 
there are techniques for allowing code to be 
extended without direct modification. 


Be careful when choosing the areas of code 
that need to he extended; applying the 
Open-Closed Principle EVERYWHERE 

is wasteful, unnecessary, and can lead to 
complex, hard to understand code. 


meet the decorator pattern 


© 
© 


Okay, enough of the “Object 
Oriented Design Club." We have real 
problems here! Remember us? Starbuzz 
Coffee? Do you think you could use 
some of those design principles to 
actually help us? 


Meet the Decorator Pattern 


Okay, we’ve seen that representing our beverage plus condiment pricing 
scheme with inheritance has not worked out very well — we get class 
explosions, rigid designs, or we add functionality to the base class that isn’t 
appropriate for some of the subclasses. 


So, here’s what we’ll do instead: we’ll start with a beverage and “decorate” 
it with the condiments at runtime. For example, if the customer wants a 


Dark Roast with Mocha and Whip, then we’ll: 


@ Take a DarkRoast object 


© Decorate it with a Mocha object 
@ Decorate it with a Whip object 


© Call the cost() method and rely on 
delegation to add on the condiment costs 


Okay, but how do you “decorate” an object, and how does delegation 
come into this? A hint: think of decorator objects as “wrappers.” Let’s 
see how this works... 
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Constructing a drink order with Decorators 


@ We start with our DarkRoast object. 


1 
———_ Remember Lnat DarkRoas Ae 


an 
Beverage 
inherits sua od that computes 
a Los 


me oe 
the ost ok the drink 


© The customer wants Mocha, so we create a Mocha 
object and wrap it around the DarkRoast. 


i tor. Its 
ha object is 3 decora _ 
ss banens the object it is only 
aunts tase, 3 Beverage: (By mit 
we mean it is fhe same LyPe- 


So, Motha has a cst) metro at 
\ mor? ism 
—o and through poly 


o a 
ever aKe fe} (because Motha ‘Ss 
) 


3) The customer also wants Whip, so we create a 
Whip decorator and wrap Mocha with it. 


Whip is a decorator, so it also 
mirrors DarkRoast’s type and 
includes a cost() method. 


So, a DarkRoast wrapped in Mocha and Whip is still 


a Beverage and we can do anything with it we can do 
with a DarkRoast, in¢luding tall its cost() method. 
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decorator characteristics 


4] Now it’s time to compute the cost for the customer. We do this 
by calling cost() on the outermost decorator, Whip, and Whip is 
going to delegate computing the cost to the objects it decorates. 
Once it gets a cost, it will add on the cost of the Whip. 
(You'll see how ™ 


&— a few pages) 


£ 


First, we call cost() on the Mocha calls cost() on 
outmost decorator, Whip. DarkRoast. 


e Whip calls cost() on Mocha. 


(4) DarkRoast 
returns its cost, 


99 cents. 
Whip adds its total, 10 cents, 
to the result from Mocha, and Mocha adds its cost, 20 
returns the final result—$1.29. 5) cents, to the result from 
DarkRoast, and returns 
the new total, $1.19. 
Okay, here’s what we know so far... 
= Decorators have the same supertype as the objects they decorate. 
= You can use one or more decorators to wrap an object. 
= Given that the decorator has the same supertype as the object it decorates, we can pass 
around a decorated object in place of the original (wrapped) object. 
Key Point 


= The decorator adds its own behavior either before and/or after delegating to the object it 
decorates to do the rest of the job. 


= Objects can be decorated at any time, so we can decorate objects dynamically at runtime 
with as many decorators as we like. 


Now let’s see how this all really works by looking at the 
Decorator Pattern definition and writing some code. 
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The Decorator Pattern defined 


Let’s first take a look at the Decorator Pattern description: 


The Decorator Pattern attaches additional 
responsibilities to an object dynamically. 


Decorators provide a flexible alternative to 
subclassing for extending functionality. 


While that describes the role of the Decorator Pattern, it doesn’t give us a lot 
of insight into how we’d apply the pattern to our own implementation. Let’s 
take a look at the class diagram, which is a little more revealing (on the next 
page we’ll look at the same structure applied to the beverage problem). 


the decorator pattern 


Component 


methodA() 
methodB() 
// other methods 


The ContreteComponent 

is the object we're going 

to dynamically add new 
behavior to. It extends “YY 


Each component can be used on its 
own, or wrapped by a decorator. 


component 


Each detorator HAS-A 
(wraps) a Component, which 
means the decorator has an 


instance variable that holds 
Component: ConcreteComponent Decorator a reference toa component. 
methodA() methodA() 
methodB() methodB() 
// other methods // other methods a Dee orators implement, ween 
face or abstract 


same inter & they 


ew 
tlass as the Compon 
ave ging, to decorate 


ConcreteDecoratorA 


ConcreteDecoratorB 


ae, Component wrappedObj 


methodA() 
The ConereteDetorator hasan method) 
instance variable for the thing newBehavior() 


// other methods 


it decorates (the Component 
the Detorator wiraps)- 


Component wrappedObj 
Object newState 


on 


Detorators can extend the 
state of the Component: 


methodA() 
methodB() 
// other methods 


Decorators can add new methods; however, new 
behavior is typically added by doing Computation 


before 


or after an existing method in the Component. 
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decorating beverages 


Decorating our Beverages 


Okay, let’s work our Starbuzz beverages into this framework... 


Beverage 
abstract compone 


atts as our 


nt Class: 


Beverage component 
description 


getDescription() 
cost) 
// other useful methods 


HouseBlend DarkRoast CondimentDecorator 

cost() cost() getDescription() 
Espresso Decaf 
cost() cost() 
Milk Mocha Soy 
ponte Beverage beverage Beverage beverage Beverage beverage Beverage beverage 

The four one YO 

we nent) cost() cost() cost() cost() 

to te e Lyre: getDescription() getDescription() getDescription() getDescription() 
U 
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\( 7A 


And here are our Condiment decorators; notice 
Mi ee to implement not only eost() but also 
escription(). We'll see why in a moment... 


get. 


VRAIN 
POWER 


Before going further, think about how you’d implement the cost() method of 
the coffees and the condiments. Also think about how you’d implement the 
getDescription() method of the condiments. 
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the decorator pattern 


Cubicle Conversation 


Some confusion over Inheritance versus Composition 


Okay, I'm a little 
confused...I thought we weren't 
going to use inheritance in this 

pattern, but rather we were going 
to rely on composition instead. 


\ Sue: What do you mean? 


/ Mary: Look at the class diagram. The CondimentDecorator is extending the Beverage class. 
That’s inheritance, right? 


Sue: True. I think the point is that it’s vital that the decorators have the same type as the 
vo objects they are going to decorate. So here we’re using inheritance to achieve the type matching, 
but we aren’t using inheritance to get behavior. 


Mary: Okay, I can see how decorators need the same “interface” as the components they wrap 
because they need to stand in place of the component. But where does the behavior come in? 


Sue: When we compose a decorator with a component, we are adding new behavior. We 
D are acquiring new behavior not by inheriting it from a superclass, but by composing objects 


w together. 


Mary: Okay, so we’re subclassing the abstract class Beverage in order to have the correct type, 
not to inherit its behavior. The behavior comes in through the composition of decorators with 
the base components as well as other decorators. 


Sue: That’s right. 


Mary: Ooooh, I sce. And because we are using object composition, we get a whole lot more 
flexibility about how to mix and match condiments and beverages. Very smooth. 


Sue: Yes, if we rely on inheritance, then our behavior can only be determined statically at 
compile time. In other words, we get only whatever behavior the superclass gives us or that we 
override. With composition, we can mix and match decorators any way we like... at runtime. 


Mary: And as I understand it, we can implement new decorators at any time to add new 
behavior. If we relied on inheritance, we’d have to go in and change existing code any time we 
wanted new behavior. 


Sue: Exactly. 


Mary: I just have one more question. If all we need to inherit is the type of the component, 
how come we didn’t use an interface instead of an abstract class for the Beverage class? 


Sue: Well, remember, when we got this code, Starbuzz already had an abstract Beverage class. 
Traditionally the Decorator Pattern does specify an abstract component, but in Java, obviously, 
we could use an interface. But we always try to avoid altering existing code, so don’t “fix” it if 
the abstract class will work just fine. 
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decorator training 


Okay, I need for you to 
make me a double mocha, 
soy latte with whip. 


New barista training 


Make a picture for what happens when the order is for a 
“double mocha soy latte with whip” beverage. Use the menu 
to get the correct prices, and draw your picture using the 
same format we used earlier (from a few pages back): 
a) 


@ whip calls cost() on Mocha. 
Mocha calls cost() on 


- mature WS for 
This pictur ee 


<—_ 5 “dark ¥08 


wihip” beverage 


@ First, we call cost() on the 
outmost decorator, Whip. 


$1.29 

(4) DarkRoast 
returns its cost, 
99 cents. 


© Whip adds its total, 10 cents, 
to the result from Mocha, and 
returns the final result—$1.29. 5) 


Mocha adds its cost, 20 
cents, to the result from 
DarkRoast, and returns 
the new total, $1.19. 


iad your pencil Draw your picture here. farbuaz Coff ee 
NS Coffees 


House Blend gg 


Dark Roast 99 
Decaf 1.05 
Espresso 1.99 
Condiments 

Steamed Milk .10 
Mocha 20 
Boy, .15 
Whap .10 
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Writing the Starbuzz code 


the decorator pattern 


It’s time to whip this design into some real code. 


Let’s start with the Beverage class, which doesn’t need to 
change from Starbuzz’s original design. Let’s take a look: 


public abstract class Beverage { 


String description = “Unknown Beverage”; 


public String getDescription() { 
return description; 


} 


public abstract double cost(); 


i 4 
goe is an abstrat 
venues the two rat 
get Deseviption.) and Cost? 


a oe getDeseription is already 


implemented for us, but we 
need to implement eost() 
in the subelasses. 


Beverage is simple enough. Let’s implement the abstract 


class for the Condiments (Decorator) as well: 


b 
Fivst, we pane a Beverage, 


1 hanged | 
Lo see pee the Beverage class 
so 


public abstract class CondimentDecorator extends Beverage { 


public abstract String getDescription(); <— 
} 


We're also going to require 

that the condiment 

decorators all reimplement the 
getDeseription() method. Again, 


we'll see why in a set... 
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implementing the beverages 


Coding beverages 


Now that we’ve got our base classes out of the way, let’s 
implement some beverages. We’ll start with Espresso. 
Remember, we need to set a description for the specific 
beverage and also implement the cost() method. 


he Beverage 
ct we extend {) 
Ao sinte this 18 4 beverage: 


public class Espresso extends Beverage { 


public Espresso() { To tak £ the description, we 
: : \P ”" ————— ° e Cave o 
} es eee set this in the constructor for the 


tlass. Remember the description instance 
variable is inherited from Beverage. 


public double cost() { 
return 1.99; 


| the cost of an Espresso: We don t 


\ t » we wust 
in condiments, wn this Class y 


an Espresso: il 4. 


ko compute 


Finally, we need : 
about addin 
a the price t 


need to retwn 


public class HouseBlend extends Beverage { 
public HouseBlend() { 
description = “House Blend Coffee”; 


} 


public double cost() { 
return .89; 


} 


Okay, here’s another Beverage. All we 
do is set the appropriate destription, 
“House Blend C fee,” and then return 
the correct cost: 84f. 


You tan create the other two Beverage classses 
(DarkRoast and Decaf) in exactly the same way. 
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Coding condiments 


If you look back at the Decorator Pattern class diagram, you'll 
see we’ve now written our abstract component (Beverage), we 
have our concrete components (HouseBlend), and we have our 
abstract decorator (CondimentDecorator). Now it’s time to 
implement the concrete decorators. Here’s Mocha: 


Low 
ald 
Metha is a detorator, so we oe ondimen | . sibs erin th 
extend CondimentDecorator. pa As Heverae We're 90in9, : eee cindy 


“ a reference 
{ (1) An instance variable te hold the 


public class Mocha extends CondimentDecorator { beverage we are wrapping, 
Beverage beverage; (2) Away to set this sidan 
Ve to the abject we ave wre 
public Mocha (Beverage beverage) { variable aes die beverage 
this. beverage = beverage; Here, were going ig ) 


tor $ 
} we've weapPing to the detora 
tor. 
public String getDescription() { consbrul . 
return beverage.getDescription() + “, Mocha”; 
} 
bon iae Genie caseu a Ree We want our description to not only 
ee he Men ree include the beverage — say “Dark 
; Roast” — but also to inelude each 
item decorating the beverage, for 
7 the cost of our beverage instance, “Dave Roast, Moe So 
Now we need ie rie delegate the call to the we first delegate to the object we are 
oe eri . atin so that rt can Compute the decorating to get its description, then 
abject we're decor atin) st of Motha te the vesult. append “, Mocha” to that deseription. 


tost; then, we add the to 


On the next page we'll actually instantiate the beverage and 
wrap it with all its condiments (decorators), but first... 


G harpen your pencil Write and compile the code for the other Soy and Whip 
N condiments. You'll need them to finish and test the application. 
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testing the beverages 


Serving some coffees 


Congratulations. It’s time to sit back, order a few coffees and marvel at 


the flexible design you created with the Decorator Pattern. 


Here’s some test code to make orders: 


public class StarbuzzCoffee { tondiments 
SSO) S 
an CSP ton and 6° 
public static void main(String args[]) { oo Order me aks gestrigeo 
Beverage beverage = new Espresso (); and een 


Now, let’s get those orders in: 
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System.out.printin (beverage.getDescription () 

+ “ S$” + beverage.cost()); bi £ 

ob ect: 

Make a DarkRoast °2) 
Beverage beverage2 = new DarkRoast();@~ Wrap it with a Mocha. 
beverage2 = new Mocha (beverage2) ; ; 
beverage2 = new Mocha (beverage2); €—— Wrap it in a second Motha. 
beverage2 = ae Whip (beverage2); <——— Wrap it ina Whip. 
System.out.println (beverage2.getDescription () 

+ “ S$” + beverage2.cost()); 


Beverage beverage3 = new HouseBlend(); 
beverage3 = new Soy (beverage3) ; Finally, give us a HouseBlend 
beverage3 = new Mocha (beverage3) ; with Soy, Motha, and Whip. 
beverage3 = new Whip (beverage3) ; 
System.out.printin (beverage3.getDescription () 

+ “ S$” + beverage3.cost()); 


* We've going to see a much better way of treating 
decorated objects when we cover the Fattory and 
Builder Design Patterns. Please note that the Builder 
Pattern is covered in the Appendix. 


| File Edit_Window Help CloudsinMyCoffee 
% java StarbuzzCoffee 

Espresso $1.99 

Dark Roast Coffee, Mocha, Mocha, Whip $1.49 


House Blend Coffee, Soy, Mocha, Whip $1.34 


% 
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Dumb Questions 


Q: I’m a little worried about code 
that might test for a specific concrete 
component - say, HouseBlend — and 

do something, like issue a discount. 
Once I’ve wrapped the HouseBlend 
with decorators, this isn’t going to work 
anymore. 


A: That is exactly right. If you have 
code that relies on the concrete component's 
type, decorators will break that code. 

As long as you only write code against 

the abstract component type, the use of 
decorators will remain transparent to your 
code. However, once you start writing code 
against concrete components, you'll want to 
rethink your application design and your use 
of decorators. 


G harpen our pencil 
a y 


: Wouldn't it be easy for some 
client of a beverage to end up with 
a decorator that isn’t the outermost 
decorator? Like if | had a DarkRoast with 
Mocha, Soy, and Whip, it would be easy 
to write code that somehow ended up 
with a reference to Soy instead of Whip, 
which means it would not include Whip in 
the order. 


A: You could certainly argue that 

you have to manage more objects with 

the Decorator Pattern and so there is 

an increased chance that coding errors 
will introduce the kinds of problems you 
suggest. However, decorators are typically 
created by using other patterns like Factory 
and Builder. Once we've covered these 
patterns, you'll see that the creation of the 
concrete component with its decorator is 
“well encapsulated” and doesn't lead to 
these kinds of problems. 


the decorator pattern 


Q: Can decorators know about the 
other decorations in the chain? Say, | 
wanted my getDescription() method to 
print “Whip, Double Mocha” instead of 
“Mocha, Whip, Mocha”? That would 

require that my outermost decorator 

know all the decorators it is wrapping. 


A: Decorators are meant to add 
behavior to the object they wrap. When 
you need to peek at multiple layers into 
the decorator chain, you are starting to 
push the decorator beyond its true intent. 
Nevertheless, such things are possible. 
Imagine a CondimentPrettyPrint decorator 
that parses the final decription and can print 
“Mocha, Whip, Mocha” as “Whip, Double 
Mocha.” Note that getDescription() could 
return an ArrayList of descriptions to make 
this easier. 


Our friends at Starbuzz have introduced sizes to their menu. You can now order 
a coffee in tall, grande, and venti sizes (translation: small, medium, and large). 


Starbuzz saw this as an intrinsic part of the coffee class, so they’ve added two 
methods to the Beverage class: setSize() and getSize(). They'd also like for the 
condiments to be charged according to size, so for instance, Soy costs 10¢, 15¢ 


and 20¢ respectively for tall, grande, and venti coffees. 


How would you alter the decorator classes to handle this change in requirements? 
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decorators in java i/o 


Real World Decorators: Java 1/0 


The large number of classes in the java.io package is... overwhelming. Don’t feel alone 
if you said “whoa” the first (and second and third) time you looked at this API. But 
now that you know the Decorator Pattern, the I/O classes should make more sense 
since the java.io package is largely based on Decorator. Here’s a typical set of 
objects that use decorators to add functionality to reading data from a file: 


A text file for reading, 


Fil el nP utStbream 


1s bein’ 


gl com? el utStream 
a Sh But ev|nP 
LineNumberlnput Stream is Fela t Str and 2 Few ON 
also a contrete decorator. BufferedInput bream Dye aie us a base Lomponen 
‘ite i 

Mery . ane is a Contrete decorator. oe ko read bytes 
count the line numbers as ———— Wiech 
it veads data. BulferedinputStream adds 


behavior in two ways: it 
buffers input to improve 
performance, and also augments 
the interface with a new 
method readline) for reading, 
tharacter—based input, a line 
at a time. 


BufferedInputStream and LineNumberInputStream both extend 
FilterInputStream, which acts as the abstract decorator class. 
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Decorating the java.io classes 


_f Filter|nputStream 
—_ is an abstract 
decorator. 


FilelnputStream StringBufferlnputStream ByteArraylnputStream FilterInputStream 


BufferedinputStream || DatalnputStream | LineNumberlnputStream ) 


These InputStreams att as } er i 
the conerete components that * 
we will wrap with decorators. | our contrete decorators. 


There are a few more we di dwt 
show, like Object|nputStream. 


PushbackinputStream 


And finally, here are al 


You can see that this isn’t so different from the Starbuzz design. You should 
now be in a good position to look over the java.io API docs and compose 
decorators on the various input streams. 


You'll see that the output streams have the same design. And you’ve probably 
already found that the Reader/Writer streams (for character-based data) 
closely mirror the design of the streams classes (with a few differences and 
inconsistencies, but close enough to figure out what’s going on). 


Java I/O also points out one of the downsides of the Decorator Pattern: 
designs using this pattern often result in a large number of small classes 

that can be overwhelming to a developer trying to use the Decorator-based 
API. But now that you know how Decorator works, you can keep things in 
perspective and when you’re using someone else’s Decorator-heavy API, you 
can work through how their classes are organized so that you can easily use 
wrapping to get the behavior you're after. 
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Writing your own Java 1/0 Decorator 


Okay, you know the Decorator Pattern, you've 
seen the I/0 class diagram. You should be ready to 
write your own input decorator. 


No problem. I just have to 
extend the FilterInputStream class 


How about this: write a decorator that converts difid averridedheread methods, 


all uppercase characters to lowercase in the 
input stream. In other words, if we read in “I 
know the Decorator Pattern therefore | RULE!” 
then your decorator converts this to “i know the 
decorator pattern therefore i rule!” 


ko import First, extend the FilterInputStream, the 
abstract decorator for all InputStreams. 


jpraios ) 


public class LowerCaseInputStream extends FilterInputStream { 


public LowerCaseInputStream(InputStream in) { ¥ 
super (in) ; 


} 


public int read() throws IOException { 
int c = super.read(); 
return (c == -l1 ? c : Character.toLowerCase((char)c)); 


} 


public int read(byte[] b, int offset, int len) throws IOException { 
int result = super.read(b, offset, len); 


for (int i = offset; i < offsettresult; i++) { Now we weed 6 implement lve 
b[i] = (byte) Character.toLowerCase ((char)b[il]); read methods. They take a 

byte (or an array of bytes) 

ees and convert each byte (that 


represents a tharacter) to 
lowertase if it’s an uppercase 
character. 

REMEMBER: we don’t provide import and package 

statements in the code listings. Get the complete 

source Code from the wickedlysmart web site. You'll 

find the URL on page xxxiii in the Intro. 
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Test out your new Java |/0 Decorator 


Write some quick code to test the 1/0 decorator: 


public class InputTest { 


the decorator pattern 


throws IOException { 


public static void main(String[] args) 
aie AGy 

try { FilelnputStr eam 
InputStream in = ——, Set uP the F : it, fie st with 

new LowerCaseInputStream ( and decorate ' kbream 

new BufferedInputStream ( 3 Butleredingy 4 new 

new FileInputStream(“test.txt”))); and then <A jereres Silter. 
LowerCaselney 


while((c = in.read()) >= 0) { 
System.out.print ((char)c); 


} 


in.close(); 
} catch (IOException e) { 
e.printStackTrace(); 


} 
} Just use the stream to read 
} characters until the end of 
file and print as we go. 


Give it a spin: 


File Edit Window Help DecoratorsRule 


% java InputTest 
i know the decorator pattern therefore i rule! 


test.txt file 


eed to 
ae his file 
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Patterns Exposed 


This week’s interview: 
Confessions of a Decorator 


HeadFirst: Welcome Decorator Pattern. We’ve heard that you’ve been a bit 
down on yourself lately? 


Decorator: Yes, I know the world sces me as the glamorous design pattern, but 
you know, I’ve got my share of problems just like everyone. 


HeadFirst: Can you perhaps share some of your troubles with us? 


Decorator: Sure. Well, you know I’ve got the power to add flexibility to 
designs, that much is for sure, but I also have a dark side. You see, I can sometimes 
add a lot of small classes to a design and this occasionally results in a design 
that’s less than straightforward for others to understand. 


HeadFirst: Can you give us an example? 


Decorator: Take the Java I/O libraries. These are notoriously difficult for 
people to understand at first. But if they just saw the classes as a set of wrappers 
around an InputStream, life would be much easier. 


HeadFirst: That doesn’t sound so bad. You’re still a great pattern, and 
improving this is just a matter of public education, right? 


Decorator: There’s more, I’m afraid. I’ve got typing problems: you see, 
people sometimes take a piece of client code that relies on specific types and 
introduce decorators without thinking through everything, Now, one great thing 
about me is that you can usually insert decorators transparently and 
the client never has to know it’s dealing with a decorator. But like I 
said, some code is dependent on specific types and when you start introducing 
decorators, boom! Bad things happen. 


HeadFirst: Well, I think everyone understands that you have to be careful 
when inserting decorators, I don’t think this is a reason to be too down on 
yourself. 


Decorator: I know, I try not to be. I also have the problem that introducing 
decorators can increase the complexity of the code needed to instantiate the 
component. Once you've got decorators, you’ve got to not only instantiate the 
component, but also wrap it with who knows how many decorators. 


HeadFirst: ’ll be interviewing the Factory and Builder patterns next week — I 
hear they can be very helpful with this? 


Decorator: That’s true; I should talk to those guys more often. 


HeadFirst: Well, we all think you’re a great pattern for creating flexible designs 
and staying true to the Open-Closed Principle, so keep your chin up and think 
positively! 


Decorator: I’ll do my best, thank you. 


Tools for your Design Toolbox 


You’ve got another chapter under 
your belt and a new principle and 
pattern in the toolbox. 


OO Principles 


oe 
Le what var" 
Encarsuls itante- 


Bits ver mher 
sition oO 
Favor Com 


the decorator pattern 


BULLET es 7 


Inheritance is one form of 
extension, but not necessarily 
the best way to achieve flexibility 
in our designs. 


In our designs we should allow 
behavior to be extended without 
the need to modify existing code. 


Composition and delegation 
can often be used to add new 
behaviors at runtime. 


The Decorator Pattern provides 
an alternative to subclassing for 
extending behavior. 


fates, not The Decorator Pattern involves 
Program te interree a set of decorator classes that 
. Vement ations: : are used to wrap concrete 
im 4 designs 
hyve for loosely courle ; components. 
Strive : anterrae’ ; ; 
Jpyects tha ——_ Decorator classes mirror the 
en ody a | 
tee be oven Lor We now have the Open ese . type of the components they 
es should Principle to guide us. We re going 
Class er tlosed for ve to design our system decorate. (In fact, they are the 
extension | Mm to pines res Baek ee same type as the components 
modixicacior . hon aarees er Se they decorate, either through 
isolated 1¥ inheritance or interface 


\ 


(ee after (or even in place of) method 
Cha | ve calls to the component. 
entae Detor ee bo an obje You can wrap a component with 
inter 4 cesponsibili Ae Ae any number of decorators. 
Nr ON 
vary | Detorators i subt Decorators are typically 
alternative transparent to the client of the 


or treating designs 


1 cue fivst pattern for Ore it 
Co And heres Cone Closed Principle. Ov . 
acentd { |s there another pattern 


st? 


veally mie follows Lis princi? 


used that 


implementation.) 


Decorators change the behavior 
of their components by adding 
new functionality before and/or 


component; that is, unless 
the client is relying on the 
component's concrete type. 


Decorators can result in many 
small objects in our design, and 
overuse can be complex. 
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exercise solutions 


Exereise solutions 


public class Beverage { 


// declare instance variables for milkCost, 
// soyCost, mochaCost, and whipCost, and 
// getters and setters for milk, soy, mocha 
// and whip. 


public double cost() { 


float condimentCost = 0.0; 
if (hasMilkQ) { 
condimentCost += milkCost; 
} 
if (hasSoy()) { 
condimentCost += soyCost; 
} 
if (nasMocha()) { 
condimentCost += mochaCost; 
} 
if (hasWhip()) { 
condimentCost += whipCost; 
} 


return condimentCost; 


New barista training 


public class DarkRoast extends Beverage { 
public DarkRoast() { 
description = “Most Excellent Dark Roast": 
public double cost() { 


return 1.99 + super.cost(); 


“double mocha soy latte with whip” 


(2) Whip calls cost() on Mocha 


First, we call cost() on the 
C1) outmost decorator, Whip. 


(11) Finally, the result returns to 
Whip’s cost(), which adds .10 and 
we have a final cost of $1.54. 
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(3) Mocha calls cost() on another Mocha. 


4) Next, Mocha calls cost() on Soy: 


(5) Last topping! Soy calls 
cost() on HouseBlend. 


(6) HouseBlend’s cost() 

method returns .89 
cents and pops off 
the stack. 


@ Soy’s cost() method 
adds .15 and returns 
the result, and pops 
off the stack. 


The second Mocha’s 

cost() method adds .20 
and returns the result, 
and pops off the stack. 


(9) The first Mocha’s cost() method 
adds .20 and returns the result, 
and pops off the stack. 
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Exereise solutions 


Our friends at Starbuzz have introduced sizes to their menu. You can now order a coffee in 
tall, grande, and venti sizes (for us normal folk: small, medium, and large). Starbuzz saw this 
as an intrinsic part of the coffee class, so they’ve added two methods to the Beverage class: 
setSize() and getSize(). They'd also like for the condiments to be charged according to size, so 
for instance, Soy costs 10¢, 15¢, and 20¢ respectively for tall, grande, and venti coffees. 


How would you alter the decorator classes to handle this change in requirements? 


public class Soy extends CondimentDecorator { 
Beverage beverage; 


ropagate the 
ve to the wrapped 


Now we need 
public Soy(Beverage beverage) { ss getSizel me 


1S 
hould also move 
, this.beverage = beverage; So beer core elass since 


\\ condiment decorators: 


public int getSize() { 
return beverage.getSize(); 


} 


public String getDescription() { 
return beverage.getDescription() + “, Soy”; 


} 


public double cost() { 
double cost = beverage.cost(); 
if (getSize() == Beverage.TALL) { a—™~ Here we get the size (which 
cost += .10; propagates all the way to the 
} else if (getSize() == Beverage.GRANDE) { tontrete beverage) and then 


cost += .15; add the appropriate cost. 
} lse i (getSize() == Beverage.VENTI) { 


cost 4 20.7 


} 


return cost; 
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4 the Factory Pattern 


aa 


4 Baking with 00 a 


Get ready to bake some loosely coupled OO designs. There is more to 
making objects than just using the new operator. You'll learn that instantiation is an activity that 
shouldn't always be done in public and can often lead to coupling problems. And you don’t want 


that, do you? Find out how Factory Patterns can help save you from embarrassing dependencies. 


this is a new chapter 109 


thinking about “new” 


Okay, it's been three chapters 
and you still haven't answered my 
question about new. We aren't supposed 
to program to an implementation but 

every time I use new, that's exactly 
what I'm doing, right? 


When you see “new”, think “concrete”. 


Yes, when you use new you are certainly instantiating a concrete 
class, so that’s definitely an implementation, not an interface. And 
it’s a good question; you’ve learned that tying your code to a 
concrete class can make it more fragile and less flexible. 


Duck duck = new MallardDuck(); 


( 


We want to use interfaces But we have to ereate an 
to keep lode flexible. anstante of a tonerete class! 


When you have a whole set of related concrete classes, often you’re 
forced to write code like this: 


Duck duck; 


if (picnic) { 
duck = new MallardDuck () —_, fo, i 
5 bunch of ditteren 


} else if (hunting) { We have 
don't know 
duck = new DecoyDuck(); duck ¢lasses, and we ; 
} else if (inBathTub) { until runtime which one We nee 
duck = new RubberDuck(); ko instantiate. 


Here we've got several concrete classes being instantiated, and the 
decision of which to instantiate is made at runtime depending on 
some set of conditions. 


When you see code like this, you know that when it comes time for 
changes or extensions, you'll have to reopen this code and examine 
what needs to be added (or deleted). Often this kind of code ends 
up in several parts of the application making maintenance and 
updates more difficult and error-prone. 


the factory pattern 


But you have to create 
an object at some point and 
Java only gives us one way to 
create an object, right? So 
what gives? 


What’s wrong with “new”? 


Technically there’s nothing wrong with new, after all, it’s a 
fundamental part of Java. The real culprit is our old friend 
CHANGE and how change impacts our use of new. 


By coding to an interface, you know you can insulate yourself 
from a lot of changes that might happen to a system down 
the road. Why? If your code is written to an interface, then 
it will work with any new classes implementing that interface 
through polymorphism. However, when you have code 


that makes use of lots of concrete classes, you’re looking for 


trouble because that code may have to be changed as new —_ Remember that d esi 


concrete classes are added. So, in other words, your code be “ 9ns should 
$ e . a a . open for ext, 7 
will not be “closed for modification.” ‘To extend it with new closed Loy HY sie but 
: mo i ee 
concrete types, you'll have to reopen it. see Chapter 3 ititation” _ 


, F for a review. 
So what can you do? It’s times like these that you can fall back 


on OO Design Principles to look for clues. Remember, our 
first principle deals with change and guides us to identify the 
aspects that vary and separate them from what stays the same. 


jee WAL 
How might you take all the parts of your application that instantiate concrete classes and 
separate or encapsulate them from the rest of your application? 


identify what varies 


Identifying the aspects that vary 


Let’s say you have a pizza shop, and as a cutting-edge pizza store 
owner in Objectville you might end up writing some code like this: 


Pizza orderPizza() { 
Pizza pizza = new Pizza(); 
pizza.prepare(); se For flexibility, we really want 
pizza.bake(); this to be an abstract class or 
pizza.cut (); interface, but we Can't diveetly 


instantiate either of those. 


pizza.box(); 


return pizza; 


But you need more than one type of pizza... 


So then you’d add some code that determines the appropriate type of pizza 
and then goes about making the pizza: 


Pizza orderPizza(String type) { We're now Passing in 
Pizza pizza; Oe the type of pizza to 
orderPizza. 


if (type.equals(“cheese”)) { 

pizza = new CheesePizza(); 
} else if (type.equals(“greek”) { 

pizza = new GreekPizza(); =<) 
} else if (type.equals(“pepperoni”) { Based on the type of pizza, we 
instantiate the correct Concrete élass 
and assign it to the pizza instance 


variable. Note that each pizza here 
has to implement the Pizza interface. 


pizza = new PepperoniPizza(); 


pizza.prepare(); 


pizza.bake(); Once we have a Pizza, we prepare it 


pizza.cut (); (you know, roll the dough, put on the 
pizza.box (); sauce and add the toppings € cheese), 
return pizza; then we bake it, cut it and box it! 

} Each Pizza subtype (CheesePizza, 


VeggiePizza, ete.) knows how to 
prepare itself. 
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the factory pattern 


But the pressure is on to add more pizza types 


You realize that all of your competitors have added a couple of trendy pizzas to 
their menus: the Clam Pizza and the Veggie Pizza. Obviously you need to keep 
up with the competition, so you'll add these items to your menu. And you haven’t 
been selling many Greek Pizzas lately, so you decide to take that off the menu: 


Pizza orderPizza(String type) { 


sed Pizza pizza; 
is 6° 4, NOT vo 
Ths e son: 

Lor ~obinea canoe? if (type.equals(“cheese”)) { 

Lyne Pi ofkerino® we pizza = new CheesePizza(); This is what varies: 
. 2 \n\S : a uw P 
vs 7 be aet te ey } : As the pi223 
earl o nod) V . = . a(); selection changes 

ro } else if (type.equals(“pepperoni”) { over time, YOU 


have te modify this 


izza = new PepperoniPizza(); 
. a a tode over and over: 


} else if (type.equals(“clam”) { 
pizza = new ClamPizza(); 
} else if (type.equals (“veggie”) { 


pizza = new VeggiePizza(); 


This is what we expect to stay 


pizza.prepare(); the same. For the most part, 
pizza.bake(); preparing, tooking, and packaging 
pizza.cut(); a pizza has remained the same 
pizza.box(); for years and years. So, we 


don’t expect this code to change, 
just the pizzas it operates on. 


return pizza; 


Clearly, dealing with which concrete class is instantiated is really messing up our 
orderPizza() method and preventing it from being closed for modification. But now 
that we know what is varying and what isn’t, it’s probably time to encapsulate it. 
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encapsulate object creation 


Encapsulating object creation 


So now we know we'd be better off moving the object creation 


out of the orderPizza() method. But how? Well, what if (type.equals(“cheese”)) { 
we're going to do is take the creation code and move it out pizza = new CheesePizza(); 
into another object that is only going to be concerned with } Cise ae (tye equals (paperaa”) | 


: : pizza = new PepperoniPizza(); 

creating pizzas. 

} else if (type.equals(“clam”) { 
pizza = new ClamPizza(); 

} else if (type.equals(“veggie”) { 


pizza = new VeggiePizza(); 


Pizza orderPizza(String type) { 


Pizza pizza; 


First we pull the object 


___——" eration tode out of the 
orderPizza Method 
pizza.prepare(); 
pizza.bake(); 


that code in an object that 


.cut(); lace 
ane ce ; dacnin to worry about how to eveate 
a sinetied ne ‘ \f any other object needs a pizza 
return pizza; What’, ie Teste Lhis is the object Lo tome to: 
} "9 to 90 heree 


We’ve got a name for this new object: we 
call it a Factory. 


Factories handle the details of object creation. Once we have by ra 
a SimplePizzaFactory, our orderPizza() method just becomes a Pepi z10r° 
client of that object. Any time it needs a pizza it asks the pizza 

factory to make one. Gone are the days when the orderPizza() 

method needs to know about Greek versus Clam pizzas. Now 

the orderPizza() method just cares that it gets a pizza, which 

implements the Pizza interface so that it can call prepare(), 


bake(), cut(), and box(). 


We've still got a few details to fill in here; for instance, what does 
the orderPizza() method replace its creation code with? Let’s 
implement a simple factory for the pizza store and find out... 
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the factory pattern 


Building a simple pizza factory 


We'll start with the factory itself, What we’re going to do is define a class that encapsulates the object 


creation for all pizzas. Here itis... 


Lhe SimplePizzaFattory- |t has 


Here's our new class, for deel exe nod ™ 
an clients. eo rae 
sob in life: creating pizzas ror | a Qh. ke 
one job wr 9 bl ee See {ns . a\ vse 
we cat vert atk 
One aa oo 
er? ue vem 
A kyo 
public class SimplePizzaFactory { we 
public Pizza createPizza(String type) { 
Pizza pizza = null; 
if (type.equals(“cheese”)) { 
pizza = new CheesePizza(); Here's the tode we 
} else if (type.equals(“pepperoni”)) { plucked out of the 
pizza = new PepperoniPizza(); orderPizzal) method. 
} else if (type.equals(“clam”)) { 
pizza = new ClamPizza(); 
} else if (type.equals(“veggie”)) { 
pizza = new VeggiePizza(); 


} 


return pizza; 


Q: What's the advantage of this? 
It looks like we are just pushing the 
problem off to another object. 


A: One thing to remember is that the 
SimplePizzaFactory may have many clients. 
We've only seen the orderPizza() method; 
however, there may be a PizzaShopMenu 
class that uses the factory to get pizzas 

for their current description and price. We 
might also have a HomeDelivery class that 
handles pizzas in a different way than our 


) 


This code is still parameterized by 
the type of the pizza, just like our 
original orderPizzal) method was. 


DIME gestions 


PizzaShop class but is also a client of the 
factory. 


Q: I’ve seen a similar design where 
a factory like this is defined as a static 
method. What is the difference? 


So, by encapsulating the pizza creating 


in one class, we now have only one 
place to make modifications when the 
implementation changes. 


Don't forget, we are also just about to 
remove the concrete instantiations from our 
client code! 


A: Defining a simple factory as a 

static method is a common technique and 

is often called a static factory. Why use a 
static method? Because you don’t need 

to instantiate an object to make use of the 
create method. But remember it also has the 
disadvantage that you can’t subclass and 
change the behavior of the create method. 
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Reworking the PizzaStore class 


Now it’s time to fix up our client code. What we want to do is rely on the 
factory to create the pizzas for us. Here are the changes: 


Now we give PizzaStore a reference 
toa SimplePizzaFactory. 


public class PizzaStore { a 


SimplePizzaFactory factory; 

public PizzaStore(SimplePizzaFactory factory) { oe gets the factory Passed to 
EMS facisery = Facey. it in the constructor. 

} 


public Pizza orderPizza(String type) { 
Pizza pizza; 


pizza = factory.createPizza(type) ; 


pizza.prepare(); find the orderPizza() method uses the 
pizza.bake(); factory to treate its pizzas by simply 
pizza.cut(); passing on the type of the order. 


pizza.box(); 


return pizza; 


} Notice that we've replaced the new 
operator with a create method on the 
// other methods here factory object, No more contrete 
instantiations here! 


BRAIN 
LP Pawere 


We know that object composition allows us to change behavior dynamically at runtime (among 
other things) because we can swap in and out implementations. How might we be able to use 
that in the PizzaStore? What factory implementations might we be able to swap in and out? 


(00} ‘UBABH MAN }96J0} Jou 
$J9]) SoUO}OR} ezzid a[Ays eluOpeD pue ‘obeayD ‘OA MAN Burpjuly} a1,9M yng ‘nod ynoge Mouy },UOP a, 
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The Simple Factory defined 


The Simple Factory isn’t actually a Design Pattern; it’s more of a programming idiom. 
But it is commonly used, so we’ll give it a Head First Pattern Honorable Mention. 
Some developers do mistake this idiom for the “Factory Pattern,” so the next time 
there is an awkward silence between you and another developer, you’ve got a nice 
topic to break the ice. 


Just because Simple Factory isn’t a REAL pattern doesn’t mean we shouldn’t check out 
how it’s put together. Let’s take a look at the class diagram of our new Pizza Store: 


This is the factory where we create 


pizzas; it should be the only part This is the product of 
of our application that refers to Lhe factory: Pizza! 
tonerete Pizza classes.. ( 
We've defined Pizza 
PizzaStore SimplePizzaFactory Pizza as or meni 
orderPizza() createPizza() prepare() with some he Pru 
bake() a implementations that 
cut() tan be overridden: 
the hod is often Box) 
This is the client of The create metho 
factory: coum declared statically: x \ 
throu} 
asa oe to aet 
CivaplePizzaractory Ke spcetian ——— 
instances pizza 


VeggiePizza ClamPizza 


These ave our contrete Products. Each 
Product needs to implement the Pizzg 
interface (which in this Case means 

extend the abstract Pizza elass”) and 

be contrete. As long as that’s the tase 

it can be ereated by the factory and , ca 
handed back to the client. 


Think of Simple Factory as a warm up. Next, we’ll explore two heavy duty patterns 
that are both factories. But don’t worry, there’s more pizza to come! 


Just another reminder: in design patterns, the phrase “implement an interface” does NOT always mean 
“write a class that implements a Java interface, by using the “implements” keyword in the class declaration.” 
In the general use of the phrase, a tontrete class implementing a method from a supertype (which Could be a 
class OR interface) is still considered to be “implementing the interface” of that supertype. 
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pizza franchise 


Franchising the pizza store 


Your Objectville PizzaStore has done so well that you’ve trounced 
the competition and now everyone wants a PizzaStore in their 
own neighborhood. As the franchiser, you want to ensure the 
quality of the franchise operations and so you want them to use 
your time-tested code. 


But what about regional differences? Each franchise might 
want to offer different styles of pizzas (New York, Chicago, and 
California, to name a few), depending on where the franchise 
store is located and the tastes of the local pizza connoisseurs. 


You want all the franchise pizza stores 
to leverage your PizzaStore code, so the 
pizzas are prepared in the same way: 


is 


PrzzqSt 0” 


> 
s 
‘3 


“Cagopizz& 


We've seen one approach... 


If we take out SimplePizzaFactory and create three different 
factories, NYPizzaFactory, ChicagoPizzaFactory and 
CaliforniaPizzaFactory, then we can just compose the PizzaStore 
with the appropriate factory and a franchise is good to go. That’s 
one approach. 


Let’s see what that would look like... 
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One franchise wants a factory 
that makes NY style pizzas: 
thin crust, tasty saute and 
justia little cheese. 


i Another franchise 


wants a factory that 
makes Chicago style 
pizzas; their customers 
like pizzas with thick 
trust, rich sauce, and 
tons of cheese. 


the factory pattern 


Here we create a factory 
for making NY style pizzas. 


NYPizzaFactory nyFactory = new NYPizzaFactory(); 
PizzaStore nyStore = new PizzaStore(nyFactory) ; —~__ 


eee ey ee Then we ereate a PizzaStore and pass it 
= a reference to the NY factory. 


and when we make pizzas, we 


get NY-styled pizzas. 


ChicagoPizzaFactory chicagoFactory = new ChicagoPizzaFactory(); 
PizzaStore chicagoStore = new PizzaStore(chicagoFactory) ; 
chicagoStore.orderPizza (“Veggie”) ; 


Likewise for the Chicago pizza stores: we create 
a factory for Chicago pizzas and create a store 
that is composed with a Chicago factory. When 
we make pizzas, we get the Chitago flavored 
ones 


But you'd like a little more quality control... 


So you test marketed the SimpleFactory idea, and what you 
found was that the franchises were using your factory to 
create pizzas, but starting to employ their own home grown 
procedures for the rest of the process: they’d bake things a 
little differently, they’d forget to cut the pizza and they’d use 
third-party boxes. 


I've been making pizza for 
years so I thought I'd add my 
own “improvements” to the 
PizzaStore procedures... 


Rethinking the problem a bit, you see that what you’d really 
like to do is create a framework that ties the store and the 
pizza creation together, yet still allows things to remain 
flexible. 


In our early code, before the SimplePizzaFactory, we had 
the pizza-making code tied to the PizzaStore, but it wasn’t 
flexible. So, how can we have our pizza and eat it too? 


i d 
+ what you want in a 900 
oe You do NOT want to know 


what he puts on his pizzas: 
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let the subclasses decide 


A framework for the pizza store 


There zs a way to localize all the pizza making activities to the PizzaStore 
class, and yet give the franchises freedom to have their own regional style. 


What we’re going to do is put the create Pizza() method back into PizzaStore, 
but this time as an abstract method, and then create a PizzaStore 
subclass for each regional style. 


First, let’s look at the changes to the PizzaStore: 


PizzaStore is now abstract (see why below). 


{ 


public abstract class PizzaStore { 


public Pizza orderPizza(String type) { 
Pizza pizza; 


Now ereatePizza is back to being a 
pizza = eee ee tall to a method in the PizzaStore 
rather than on a factory object: 
pizza.prepare(); 

pizza.bake(); 


pizza.cut(); 
Presa Oe) 5 nee All this looks just the same-. 


return pizza; 


— 


abstract Pizza createPizza(String type); Now we've moved out factor 


object to this method. 


Our “factory method” is now 
abstract in PizzaStore. 


Now we’ve got a store waiting for subclasses; we’re going to have a 

subclass for each regional type (NYPizzaStore, ChicagoPizzaStore, 
CaliforniaPizzaStore) and each subclass is going to make the decision about 
what makes up a pizza. Let’s take a look at how this is going to work. 
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the factory pattern 


Allowing the subclasses to decide 


Remember, the PizzaStore already has a well-honed order system in the orderPizza() 
method and you want to ensure that it’s consistent across all franchises. 


What varies among the regional PizzaStores is the style of pizzas they make — New York 
Pizza has thin crust, Chicago Pizza has thick, and so on ~ and we are going to push all 
these variations into the createPizza() method and make it responsible for creating the 
right kind of pizza. The way we do this is by letting each subclass of PizzaStore define 
what the createPizza() method looks like. So, we will have a number of concrete subclasses 
of PizzaStore, each with its own pizza variations, all fitting within the PizzaStore 
framework and still making use of the well-tuned orderPizza() method. 


Each subclass overrides the ereatePizza() 
method, while all subclasses make use 


PizzaStore of the orderPizzal) method defined 
createPizza() in PizzaStore. We could make the 
orderPizza() orderPizzal) method final if we really 


wanted to enforce this. 


—~ 


NYStylePizzaStore ChicagoStylePizzaStore Gimilarly, by using Lig 
createPizza() createPizza() Chieage sibslass — bah 
implementation of ereatePizzal) 
with Chitago ingredients. 


oe, 


If a franchise wants NY style 
pizzas Lor its customers, it 
uses the NY subelass, which has 


its own treatePizzal) method, Remember: eveatePizzal) is 
eveating NY style pizzas abstratt in PizzaStore, so all 
pizza store subtypes MUST 
( implement the method. 
public Pizza createPizza(type) { 
public Pizza createPizza(type) { if (type.equals(“cheese”)) { 
if (type.equals(“cheese”)) { pizza = new ChicagoStyleCheesePizza(); 
pizza = new NYStyleCheesePizza(); } else if (type.equals(“pepperoni”) { 
P Guliexss shir (Hegsiaaceiallis (Maceo) af pizza = new ChicagoStylePepperoniPizza(); 
pizza = new NYStylePepperoniPizza(); } else if (type.equals(“clam”) { 
} else af (type.equalis((“clam”) { pizza = new ChicagoStyleClamPizza(); 
pizza = new NYStyleClamPizza(); } else if (type.equals(“veggie”) { 
} else if (type. equals (“veqgre”)) { pizza = new ChicagoStyleVeggiePizza(); 


pizza = new NYStyleVeggiePizza(); } 
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how do subclasses decide? 


I don't get it. The 

PizzaStore subclasses are just 
subclasses. How are they deciding 
anything? I don't see any logical decision- 
making code in NYStylePizzaStore.... 


Well, think about it from the point of view of the PizzaStore’s orderPizza() method: it is 
defined in the abstract PizzaStore, but concrete types are only created in the subclasses. 


in the abstract 


PizzaStore ee derPizzal) is defined Co, the 
createPizza() PizzaStore, not the subclasses: es uals 
orderPizza() method has no idea which subclass * 

makind, the pizzas. 


runnind, the code and 


Now, to take this a little further, the orderPizza() method does a lot of things with a 
Pizza object (like prepare, bake, cut, box), but because Pizza is abstract, orderPizza() has 
no idea what real concrete classes are involved. In other words, it’s decoupled! 


pane pizza = createPizza(); 
createPizza() Pica enente 
OrderPizZa() +++2seeeee ee Pees eee ceeeeeeeees pizza.bake(); 
pizza.cut(); 


( pizza.box(); 


orderPizza() calls ereatePizzal) to actualy 9¢ 
izza object: But which kind of pizza vi " 
pe : wza() method tant decide; it 


et? The orderP ee 
senile know how. So who does decides 


When orderPizza() calls createPizza(), one of your subclasses will be called into action to 
create a pizza. Which kind of pizza will be made? Well, that’s decided by the choice of 
pizza store you order from, NYStylePizzaStore or ChicagoStylePizzaStore. 


a ai 


NYStylePizzaStore ChicagoStylePizzaStore 


createPizza() createPizza() 


So, 1s there a real-time decision that subclasses make? No, but from the perspective of 
orderPizza(), if you chose a NYStylePizzaStore, that subclass gets to determine which 
pizza is made. So the subclasses aren’t really “deciding” — it was you who decided by 
choosing which store you wanted — but they do determine which kind of pizza gets made. 
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the factory pattern 


Let’s make a PizzaStore 


Being a franchise has its benefits. You get all the PizzaStore 
functionality for free. All the regional stores need to do is subclass 
PizzaStore and supply a createPizza() method that implements 
their style of Pizza. We'll take care of the big three pizza styles for 
the franchisees. 


Here’s the New York regional style: 


treatePizzal) returns 3 aes — The NYPizzaStore extends 
subtlass is fully responsible ene PizzaStore, so it inherits the 
tontrete Pizza it instantiates orderPizza() method (among others). 


public class NYPizzaStore extends PizzaStore { 


&— We've got to implement 


Pizza createPizza(String item) { ereatePizzal), since it is 
if (item.equals(“cheese”)) { abstract in PizzaStore. 
return new NYStyleCheesePizza(); 
} else if (item.equals(“veggie”)) { 
t leV LePi 4 
wae i eae itera S Soe eee) a Here’s where we create our 
} else if (item.equals(“clam”)) { Cnbeste Hues, Corea 
return new NYStyleClamPizza(); of P; meee ‘ype 
} else if (item.equals(“pepperoni”)) { izza we create the NY style. 


return new NYStylePepperoniPizza(); 
} else return null; 


Note that the orderPizza() method in the 
superclass has no Clue which Pizza we are treating; it 
just knows it can prepare, bake, cut, and box it! 


Once we’ve got our PizzaStore subclasses built, it will be time 
to see about ordering up a pizza or two. But before we do that, 
why don’t you take a crack at building the Chicago Style and 
California Style pizza stores on the next page. 
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factory 


G harpen our pencil 
a y 


We've knocked out the NYPizzaStore, just two more to go and we'll be ready to franchise! 
Write the Chicago and California PizzaStore implementations here: 
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the factory pattern 


Declaring a factory method 


With just a couple of transformations to the PizzaStore we’ve gone from 
having an object handle the instantiation of our concrete classes to a set of 
subclasses that are now taking on that responsibility. Let’s take a closer look: 


The subclasses of . 
public abstract class PizzaStore { PizzaStore handle man 
instantiation for us in the 
eveatePizzal) method: 
public Pizza orderPizza(String type) { 
a Sa NYStylePizzaStore 
5 E createPizza() 
pizza = createPizza(type); 
= : : : . oS : - OF ChicagoStylePizzaStore 
si poe . sees createPizza() 


pizza.box(); 


return pizza; 


} 


All the cesponsibility Lor 
instantiating Pizzas has been 


// other methods here moved into a method that 
} atts as a Factory: 


J Code Up Clase 


A factory method handles object creation and encapsulates it in 


protected abstract Pizza createPizza(String type); 


a subclass. This decouples the client code in the superclass from fj Sactory method may be 


the object creation code in the subclass. parame Levized (or 
[ag] 
ko select among SeY 
duct: 
variations of a pre 
abstract Product factoryMethod (String type) 
A factor ~~ 
method j : lient (the 
abstract 7 the oy A factory method returns A factory method — ae: 
are Counted on ie ASSES 5 Produtt that is typically tode in the superclass) hi ‘. een 
object Creation mndle used within methods defined from knowing what ae d 
: - the superclass. Product is actually created. 
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ordering a pizza 


Let’s see how it works: ordering pizzas with 
the pizza factory method 


T like NY Style pizza... you 
know, thin, crispy crust 
with a little cheese and 
really good sauce. 


T like Chicago style deep dish 
pizza with thick crust and 
tons of cheese. 


Ethan needs to order 


his pizza from a NY Joel needs to order his 


Pizza store. pizza from a Chicago 
pizza store. Same pizza 
ordering method, but 
different kind of pizzal 

So how do they order? 
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@ First, Joel and Ethan need an instance of a PizzaStore. Joel needs to instantiate a 


ChicagoPizzaStore and Ethan needs a NYPizzaStore. 


2] With a PizzaStore in hand, both Ethan and Joel call the orderPizza() method and pass 


in the type of pizza they want (cheese, veggie, and so on). 


3) To create the pizzas, the createPizza() method 1s called, which is defined in the 


two subclasses NYPizzaStore and ChicagoPizzaStore. As we defined them, the 
NYPizzaStore instantiates a NY style pizza, and the ChicagoPizzaStore instantiates 
Chicago style pizza. In either case, the Pizza is returned to the orderPizza() method. 


4 | The orderPizza() method has no idea what kind of pizza was created, but it knows it is 


a pizza and it prepares, bakes, cuts, and boxes it for Ethan and Joel. 


Chapter 4 


the factory pattern 


Let’s check out how these pizzas are Behind 
really made to order... the Scene 


‘a Let’s follow Ethan’s order: first we need a NY PizzaStore: 


= new NYPizzaStore(); 


PizzaStore nyPizzaStore = 
Ne Creates a instanée of 


NYPizzaStore. ——__> 


Now that we have a store, we can take an order: 
2) : Nir 


nyPizzaStore.orderPizza (“cheese”) ; oD 
‘ The orderPizza() method is called on 


Love instance (the method 


izzaS 
the nyP izzaStore runs): 


defined inside P 


createPizza (“cheese”) 


3) The orderPizza() method then calls the createPizza() 
method: 


Pizza pizza = createPizza (“cheese”) ; 
Remember, ereatePizza(), the factory 
method, is implemented in the subclass. In 


this case it returns a NY Cheese Pizza- “> 


Pizza 


4) Finally we have the unprepared pizza in hand and the 
orderPizza() method finishes preparing it: 


pizza.prepare(); 


oe pee ; Ss All of these methods - — 
| —_ in the specific pizza returne 
— =“ Crom the faetory method 
ereatePizzal), defined in the 


The orderPizzal) method gets Ae 
back a Pizza, without knowing 
exactly what contrete elass it is. 
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the pizza classes 


We're just missing one thing: PIZZA! 


Our PizzaStore isn’t going to be very popular 
without some pizzas, so let’s implement them: 


. abstract 
welt start wh aN he contvete 


f class and “ 
C will deve Crom this 
y 


public abstract class Pizza { Each Pizza has a name, 


String name; 
String dough; a 
String sauce; 


ArrayList toppings = new ArrayList(); 


a type of dough, a 
type of saute, and a set of toppings. 


void prepare() { The abstract class provides 
System.out.println(“Preparing “ + name); some basit defaults for baking, 
System.out.printin(“Tossing dough...”); cutting and boxing, 
( 


System.out.printlin(“Adding sauce...”); 
System.out.printlin(“Adding toppings: “); 
for (int i= 0; i < toppings.size(); itt) { 


System.out.println (“ “ + toppings.get(i)); 
} Preparation follows a 
} number of steps in a 


particular sequence: 
void bake() { 


System.out.printin(“Bake for 25 minutes at 350”); 
} 


void cut() { 
System.out.printlin(“Cutting the pizza into diagonal slices”); 


} 


void box() { 
System.out.printin(“Place pizza in official PizzaStore box”); 


} 


public String getName() { 
return name; 


} 


REMEMBER: we don't provide import and package statements in the 
tode listings. Get the complete source code from the wickedlysmart 
web site. You'll find the URL on Page xxxiii in the Intro. 
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Now we just need some concrete subclasses... how about defining 
New York and Chicago style cheese pizzas? 


The NY Pizza has its own x 
public class NYStyleCheesePizza extends Pizza { marinara style sauce and thin Cru 


public NYStyleCheesePizza() { 
name = “NY Style Sauce and Cheese Pizza”; 
dough = “Thin Crust Dough”; 
sauce = “Marinara Sauce”; 


toppings.add(“Grated Reggiano Cheese”); 


} And one topping, 


reggiano cheese! 


The Chicago Pizza uses plum 
Lomatoes as a sauce along 
public class ChicagoStyleCheesePizza extends Pizza { with extra thick erust. 


public ChicagoStyleCheesePizza() { 
name = “Chicago Style Deep Dish Cheese Pizza”; 


dough = “Extra Thick Crust Dough”; 
sauce = “Plum Tomato Sauce”; 
a The Chicago style deep 
toppings.add(“Shredded Mozzarella Cheese”) ; dish pizza has lots i 
3: 
} mozzarella cheese! 
void cut() { 


System.out.printlin(“Cutting the pizza into square slices”); 


) 


The Chicago style pizza also overrides the eut() 
method so that the pieces are Cut into squares. 
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make some pizzas 


You've waited long enough, time for some pizzas! 


two 
. we ereate 
public class PizzaTestDrive { First 


gifferent stores 
public static void main(String[] args) { 


: . e@ one one store 
PizzaStore nyStore = new NYPizzaStore(); Then . eu ee 
PizzaStore chicagoStore = new ChicagoPizzaStore(); to make an 


Pizza pizza = nyStore.orderPizza (“cheese”) ; 
System.out.println(“Ethan ordered a “ + pizza.getName() + “\n”); 


pizza = chicagoStore.orderPizza (“cheese”) ; 
System.out.println(“Joel ordered a “ + pizza.getName() + “\n”); 


And the other for Joel’s. 


File Edit_ Window Help YouWantMootzOnThatPizza? 


Sjava PizzaTestDrive 


Preparing NY Style Sauce and Cheese Pizza 
Tossing dough... 
Adding sauce... 
Adding toppings: 

Grated Reggiano cheese 
Bake for 25 minutes at 350 : red, 
Cutting the pizza into diagonal slices Both Sees ee the 
Place pizza in official PizzaStore box the toppings added, 


Ethan ordered a NY Style Sauce and Cheese Pizza pizzas baked, cut and boxed. 
Our superclass never had to 


Preparing Chicago Style Deep Dish Cheese Pizza know the details, the subclass 


Tossing dough... handled all that just by 

aries Ses instantiating, the right pizza: 
Shredded Mozzarella Cheese 

Bake for 25 minutes at 350 

Cutting the pizza into square slices 

Place pizza in official PizzaStore box 

Joel ordered a Chicago Style Deep Dish Cheese Pizza 
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It’s finally time to meet the Factory Method Pattern 


All factory patterns encapsulate object creation. The Factory Method Pattern encapsulates 
object creation by letting subclasses decide what objects to create. Let’s check out these class 
diagrams to see who the players are in this pattern: 


The Creator classes 


This is our abstract ne LN he creator contains ¢ode that 
class. It defines -. Fria a pati - abclenth product, whith 
actory method that the PizzaStore is produced by a subelass. The ereator 
subélasses implement to soaker never really knows which Conerete 
pradite Products. orderPizza() product was produced. 


ae each franchise gets its 


NYPizzaStore ChicagoPizzaStore own subelass of oaraaaiia 

createPizza() createPizza() it’s Free to create as 

Re own style of pizza by 
'S our fotPieza( meth yO implementing ereatePizzal). 

ac od 
Produces Pr a. method. im Classes that produce 
oducts oducts ave called 
paar creators 
The Product classes 


—~ Factories produce products, 


Pizza and in the PizzaStore, our 
product is a Pizza. 
These are the conerete 
products — all the pizzas that 
are produced by our stores. NYStyleCheesePizza " ChicagoStyleCheesePizzaly 
os NYStylePepperoniPizza b ChicagoStylePepperoniPizza 
= NYStyleClamPizza " = ChicagoStyleClamPizza 


NYStyleVeggiePizza = ChicagoStyleVeggiePizza 
—= — 
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creators and products 


Another perspective: parallel class hierarchies 


We’ve seen that the factory method provides a framework by supplying an 
orderPizza() method that is combined with a factory method. Another way to look 
at this pattern as a framework is in the way it encapsulates product knowledge into 
each creator. 


Let’s look at the two parallel class hierarchies and see how they relate: 


Notice how these 


class hierarchies are 
parallel: both have —_, 
abstract classes that 


a + nded b 
The Product classes hostels theese which The Creator classes 


know about specific 
implementations for NY 


Pizza and Chicago. PizzaStore 


createPizza() 


orderPizza() 


NYStyleCheesePizza b ChicagoStyleCheesePizza), NYPizzaStore ChicagoPizzaStore 
| NYStylePepperoniPizza |ChicagoStylePepperoniPizza |) createPizza() createPizza() 
NYStyleClamPizza " ChicagoStyleClamPizza 


NYStyleVeggiePizza ChicagoStyleVeggiePizza ( ie! } 
i __ 2 
et ee kp coke 
xe re a 
.® c 


S Z 
a a) N N Kp 
Ce) o re wee spor ee 
ent ed 5 dhe 
row cnee 
Pry: 
psulating this knowledge: 


T he Laetory mm Lhod \s the key to enta 
ta 
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of course). Draw another parallel set of classes that you’d need to add a new 


California region to our PizzaStore. 


RS Design Puzzle 


We need another kind of pizza for those crazy Californians (crazy in a good way 


PizzaStore 


createPizza() 


orderPizza() 


NYPizzaStore 


ChicagoPizzaStore 


NYStyleCheesePizza " 


NYStylePepperoniPizza " 


—| 


| 


Okay, now write the five most bizarre things you can think of to put on a pizza. 
Then, you'll be ready to go into business making pizza in California! 


NYStyleClamPizza " 


createPizza() 


| NYStyleVeggiePizza 


createPizza() 


ChicagoStyleCheesePizza) 


ChicagoStylePepperoniPizza " 


— 


ChicagoStyleClamPizza 


| 


| ChicagoStyleVeggiePizza 


the factory pattern 


you are here > 
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factory method defined 


Factory Method Pattern defined 


It’s time to roll out the official definition of the Factory Method Pattern: 


The Factory Method Pattern defines an interface 
for creating an object, but lets subclasses decide which 


class to instantiate. Factory Method lets a class defer 
instantiation to subclasses. 


As with every factory, the Factory Method Pattern gives us a way to encapsulate the 
instantiations of concrete types. Looking at the class diagram below, you can see that the 
abstract Creator gives you an interface with a method for creating objects, also known as the 
“factory method.” Any other methods implemented in the abstract Creator are written to 
operate on products produced by the factory method. Only subclasses actually implement 


wnat 
the factory method and create products. oo ax © vk 
Ne » ans) . 
As in the official definition, you’ll often hear developers say that the Factory Method lets wgetide® ae nd i 
subclasses decide which class to instantiate. They say “decide” not because the pattern i do. 


: : Seaee 4c = \nan trey 
allows subclasses themselves to decide at runtime, but because the creator class is written pecter 


without knowledge of the actual products that will be created, which is decided purely by 
the choice of the subclass that is used. 


hat contains 
The Creator is 3 are all of the 


im lementations 
{ rn to manipulate products, 
except for the fae 


~? Product Creator 


All products must implement factoryMethod!) 


anOperation() 


The abstract factoryMethod() 
is what all Creator subclasses 
must implement. 


the same inter 

ith use 
classes whi 
tan vere to the interxace 


not the tonerete class: 


\ 


The ConereteCreator 
ConcreteProduct ConcreteCreator : th 
factoryMethod() implements the 
— faetoryMethod(), whith is 


the method that attually 
\ produces products. 


The ContreteCreator is responsible for 
creating one or more Contrete products. [t 
is the only class that has the knowledge of 
how to ereate these products. 
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Dri Gtestions 


+ What’s the advantage of the Factory Method 
Pattern when you only have one ConcreteCreator? 


A: The Factory Method Pattern is useful if 

you've only got one concrete creator because you are 
decoupling the implementation of the product from 

its use. If you add additional products or change a 
product’s implementation, it will not affect your Creator 
(because the Creator is not tightly coupled to any 
ConcreteProduct). 


+ Would it be correct to say that our NY and 
Chicago stores are implemented using Simple 
Factory? They look just like it. 


A: They're similar, but used in different ways. Even 
though the implementation of each concrete store looks 
a lot like the SimplePizzaFactory, remember that the 
concrete stores are extending a class which has defined 
createPizza() as an abstract method. It is up to each 
store to define the behavior of the createPizza() method. 
In Simple Factory, the factory is another object that is 
composed with the PizzaStore. 


+ Are the factory method and the Creator 
always abstract? 


A: No, you can define a default factory method 

to produce some concrete product. Then you always 
have a means of creating products even if there are no 
subclasses of the Creator. 


+ Each store can make four different kinds 
of pizzas based on the type passed in. Do all 
concrete creators make multiple products, or do they 
sometimes just make one? 


the factory pattern 


A: We implemented what is known as the 
parameterized factory method. It can make more than 
one object based on a parameter passed in, as you 
noticed. Often, however, a factory just produces one 
object and is not parameterized. Both are valid forms 
of the pattern. 


* Your parameterized types don’t seem “type- 
safe.” I’m just passing in a String! What if | asked for 
a “CalmPizza”? 


A: You are certainly correct and that would cause, 
what we call in the business, a “runtime error.” There 
are several other more sophisticated techniques that 

can be used to make parameters more “type safe’, or, 
in other words, to ensure errors in parameters can be 

caught at compile time. For instance, you can create 

objects that represent the parameter types, use static 
constants, or, in Java 5, you can use enums. 


Q: I’m still a bit confused about the difference 
between Simple Factory and Factory Method. They 
look very similar, except that in Factory Method, the 
class that returns the pizza is a subclass. Can you 
explain? 


: You're right that the subclasses do look a lot 
like Simple Factory, however think of Simple Factory 
as a one shot deal, while with Factory Method you are 
creating a framework that lets the subclasses decide 
which implementation will be used. For example, the 
orderPizza() method in the Factory Method provides a 
general framework for creating pizzas that relies on a 
factory method to actually create the concrete classes 
that go into making a pizza. By subclassing the 
PizzaStore class, you decide what concrete products 
go into making the pizza that orderPizza() returns. 
Compare that with SimpleFactory, which gives you a 
way to encapsulate object creation, but doesn't give 
you the flexibility of the Factory Method because there 
is no way to vary the products you're creating. 
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master and student 


136 


Master and Student... 
Master: Grasshopper, tell me how your training is going? 


Student: Master, | have taken my study of “encapsulate what 
varies” further. 


Master: Go on... 


Student: | have learned that one can encapsulate the code that 
creates objects. When you have code that instantiates concrete 
classes, this is an area of frequent change. I’ve learned a 
technique called “factories” that allows you to encapsulate this 
behavior of instantiation. 


Master: And these “factories,” of what benefit are they? 


Student: There are many. By placing all my creation code in one 
object or method, | avoid duplication in my code and provide one 
place to perform maintenance. That also means clients depend 
only upon interfaces rather than the concrete classes required to 
instantiate objects. As | have learned in my studies, this allows me 
to program to an interface, not an implementation, and that makes 
my code more flexible and extensible in the future. 


Master: Yes Grasshopper, your OO instincts are growing. Do 
you have any questions for your master today? 


Student: Master, | know that by encapsulating object creation 
| am coding to abstractions and decoupling my client code from 
actual implementations. But my factory code must still use 
concrete classes to instantiate real objects. Am | not pulling the 
wool over my own eyes? 


Master: Grasshopper, object creation is a reality of life; we must 
create objects or we will never create a single Java program. But, 
with knowledge of this reality, we can design our code so that we 
have corralled this creation code like the sheep whose wool you 
would pull over your eyes. Once corralled, we can protect and 
care for the creation code. If we let our creation code run wild, 
then we will never collect its “wool.” 


Student: Master, | see the truth in this. 


Master: As | knew you would. Now, please go and meditate on 
object dependencies. 


the factory pattern 


A very dependent PizzaStore 


GeSharpen your pencil 
ere yer 


Let’s pretend you've never heard of an OO factory. Here’s a version of the PizzaStore that 


doesn’t use a factory; make a count of the number of concrete pizza objects this class is 


dependent on. If you added California style pizzas to this PizzaStore, how many objects would it 


be dependent on then? 


public class DependentPizzaStore { 


public Pizza createPizza(String style, 


String type) { 


Pizza pizza = null; 
if (style.equals (“NY”) ) 
if (type.equals(“cheese”)) { 
pizza = new NYStyleCheesePizza(); 
} else if (type.equals (“veggie”)) { Handles all the NY 
pizza = new NYStyleVeggiePizza(); : 
} else if (type.equals(“clam”)) { style pizzas 
pizza = new NYStyleClamPizza(); 
} else if (type.equals(“pepperoni”)) { 
pizza = new NYStylePepperoniPizza(); 


} else if 


} else 


} 


} 
(style.equals(“Chicago”)) { 


if (type.equals(“cheese”)) { 
pizza new ChicagoStyleCheesePizza(); Handles all the 
} else if (type.equals (“veggie”)) { Chicago style 
pizza new ChicagoStyleVeggiePizza(); . 
pizzas 


( 
} else if (type.equals(“clam”)) { 
( 


pizza new ChicagoStyleClamPizza(); 
} else if (type.equals (“pepperoni”)) { 
pizza new ChicagoStylePepperoniPizza(); 


System.out.printlin(“Error: 
return null; 


invalid type of pizza”); 


pizza.prepare(); 
pizza.bake(); 
pizza.cut(); 
pizza.box(); 
return pizza; 


You can write 
your answers here: 


th California t° 


number number wi 
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object dependencies 


Looking at object dependencies 


When you directly instantiate an object, you are depending on its 
concrete class. Take a look at our very dependent PizzaStore one 
page back. It creates all the pizza objects right in the PizzaStore class 
instead of delegating to a factory. 


If we draw a diagram representing that version of the PizzaStore 
and all the objects it depends on, here’s what it looks like: 


This version of the 
PizzaStore depends on all 
those pizza objects, because 
te it’s creating them directly. 
he implementat Because any changes to the contrete 
Classes change, ‘i of these ) eee ae i; pizzas affeets the 
have to modify ee PizzaStore, we say that the PizzaStore 


in Pi 
zzaS tore. “depends on the pizza implementations. 


is} 
N 
2 
& 
, TeP ep 
> se 
L g a eas 
S ay 
Y S 
“epp ee 
ce Ag 
Vecak 


Every new kind of pizza 
we add creates another w 


dependency for PizzaStore. 
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The Dependency Inversion Principle 


It should be pretty clear that reducing dependencies to 

concrete classes in our code is a “good thing.” In fact, we’ve 

got an OO design principle that formalizes this notion; it even 

has a big, formal name: Dependency Inversion Principle. y\ek another 


Here’s the general principle: | wr raise wil 


the admiration 
fellow developers: 


Design Principle 


Depend upon abstractions. Do 
not depend upon concrete classes. 


At first, this principle sounds a lot like “Program to an 
interface, not an implementation,” right? It is similar; 
however, the Dependency Inversion Principle makes an even 
stronger statement about abstraction. It suggests that our 


high-level components should not depend on our low-level 
components; rather, they should both depend on abstractions. 


But what the heck does that mean? 


Well, let’s start by looking again at the pizza store diagram 
on the previous page. PizzaStore is our “high-level 
component” and the pizza implementations are our “low- 
level components,” and clearly the PizzaStore is dependent 
on the concrete pizza classes. 


Now, this principle tells us we should instead write our code 
so that we are depending on abstractions, not concrete 
classes. That goes for both our high level modules and our 
low-level modules. 


But how do we do this? Let’s think about how we’d 
apply this principle to our Very Dependent PizzaStore 
implementation... 


A “high-level” Component is a Class 
with behavior defined in terms of 
other, “low level” components. 
For example, PizzaStore is a 
high-level component because 
its behavior is defined in terms 
of pizzas — it ereates all the 
different pizza objects, prepares, 
bakes, cuts, and boxes them, while 
the pizzas it uses are low-level 
components. 
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dependency inversion principle 
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Applying the Principle 


Now, the main problem with the Very Dependent PizzaStore 1s that it depends 


on every type of pizza because it actually instantiates concrete types in its 
orderPizza() method. 


While we’ve created an abstraction, Pizza, we’re nevertheless creating concrete 
Pizzas in this code, so we don’t get a lot of leverage out of this abstraction. 


How can we get those instantiations out of the orderPizza() method? Well, as 
we know, the Factory Method allows us to do just that. 


So, after we’ve applied the Factory Method, our diagram looks like this: 


—_ 
PizzaStore now depends only 
Pema on Pizza, the abstract class: 


Pizza is an abstract | 


d on 
¢lass...an abstraction, ~ depend o' 


evete pizza classes 
- i <i abstraction too, because they 


i plement the Pizza interface (remember; 


ae cal 
we're using “aterface in the gene 


\ OF sense) in the P 
O: 


Pizza 
1zzZa abstract lass. 


After applying the Factory Method, you'll notice that our high-level component, 
the PizzaStore, and our low-level components, the pizzas, both depend on Pizza, 
the abstraction. Factory Method is not the only technique for adhering to the 
Dependency Inversion Principle, but it is one of the more powerful ones. 


Chapter 4 


the factory pattern 


Okay, I get the dependency 
part, but why is it called 
dependency inversion? 


Where’s the “inversion” in Dependency 
Inversion Principle? 


The “inversion” in the name Dependency Inversion 


x ho Principle is there because it inverts the way you 
g typically might think about your OO design. Look 
foe | at the diagram on the previous page, notice that the 


low-level components now depend on a higher level 
abstraction. Likewise, the high-level component 

is also tied to the same abstraction. So, the top-to- 
bottom dependency chart we drew a couple of pages 
back has inverted itself, with both high-level and low- 
level modules now depending on the abstraction. 


| an Let’s also walk through the thinking behind the typical 
| design process and see how introducing the principle 
can invert the way we think about the design... 
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invert your thinking 


Inverting your thinking... 


Hmmm, Pizza Stores prepare, bake and 
box pizzas. So, my store needs to be 
able to make a bunch of different 
pizzas: CheesePizza, VeggiePizza, 
ClamPizza, and so on... 


Well, a CheesePizza and a 
VeggiePizza and a ClamPizza 

are all just Pizzas, so they 

should share a Pizza interface. 


Since I now have a Pizza 
abstraction, I can design my 

Pizza Store and not worry about 
the concrete pizza classes. 


Okay, so you need to implement a PizzaStore. 
What’s the first thought that pops into your head? 


Right, you start at top and follow things down to 
the concrete classes. But, as you’ve seen, you don’t 
want your store to know about the concrete pizza 
types, because then it’ll be dependent on all those 
concrete classes! 


9, 66 


Now, let’s “invert” your thinking... instead of 
starting at the top, start at the Pizzas and think 
about what you can abstract. 


Right! You are thinking about the abstraction 
Pizza. So now, go back and think about the design 
of the Pizza Store again. 


Close. But to do that you'll have to rely on a 
factory to get those concrete classes out of 

your Pizza Store. Once you've done that, your 
different concrete pizza types depend only on an 
abstraction and so does your store. We’ve taken 
a design where the store depended on concrete 
classes and inverted those dependencies (along 
with your thinking). 


the factory pattern 


A few guidelines to help you follow the 
Principle... 


The following guidelines can help you avoid OO designs that violate | on 
the Dependency Inversion Principle: ; wee . “atin 
a reference to a tonerete Class- 


] 
——_ Use a factory to get around that! 


® No variable should hold a reference to a concrete class. 


\f you derive Lrom a contrete Class, 

you're depending, on a contrete class. 
=" No class should derive from a concrete class. a Derive from an abstraction ide ah 

interface or an abstract class. 


If You overrid : 
'1de an imp] 
" No method should override an implemented method of {-—~ then your base dss wae cal 


any of its base classes. abstraction to start with. Th 


wire TPemented in the base ¢lass are 
¢ shared by all Your subélasses, 


ose 


But wait, aren't these 
guidelines impossible to follow? 
If I follow these, I'll never be 

able to write a single program! 


You’re exactly right! Like many of our principles, this is a guideline 
you should strive for, rather than a rule you should follow all the time. 
Clearly, every single Java program ever written violates these guidelines! 


But, if you internalize these guidelines and have them in the back of q 

your mind when you design, you'll know when you are violating the hi} 

principle and you'll have a good reason for doing so. For instance, if you g | 

have a class that isn’t likely to change, and you know it, then it’s not the 

end of the world if you instantiate a concrete class in your code. Think \ 
about it; we instantiate String objects all the time without thinking twice. 

Does that violate the principle? Yes. Is that okay? Yes. Why? Because 

String is very unlikely to change. 


If, on the other hand, a class you write is likely to change, you have some 
good techniques like Factory Method to encapsulate that change. 


iV 


vs 
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families of ingredients 


Meanwhile, back at the PizzaStore... 


The design for the PizzaStore is really shaping up: it’s got 


a flexible framework and it does a good job of adhering to Dough 
design principles. 


Now, the key to Objectville Pizza’s success has always been Pepperoni 
fresh, quality ingredients, and what you’ve discovered is that 
with the new framework your franchises have been following 
your procedures, but a few franchises have been substituting 
inferior ingredients in their pies to lower costs and increase 
their margins. You know you've got to do something, 


because in the long term this is going to hurt the Objectville 
brand! 


Ensuring consistency in your 
ingredients 


So how are you going to ensure each franchise is using quality ingredients? Sauce 


You’re going to build a factory that produces them and ships them to your 
franchises! 


Veagies 


Cheese 


Now there is only one problem with this plan: the franchises are located in 
different regions and what is red sauce in New York is not red sauce in Chicago. 
So, you have one set of ingredients that needs to be shipped to New York and a 
different set that needs to be shipped to Chicago. Let’s take a closer look: 


Chicago 
Pizza Menu 
Cheese Pizza 


Plum Tomato Sauce, Mozzarella, Parmesan, 
Oregano 


We've got the ; 
same product Tew Y Ot 


families (dough, Dp Ws 
sauce, cheese, (ZZA enu 
veggies, meats) 


: Cheese Pizza 
but different Marinara Sauce, Reggiano, Garlic 


i ntations a 
Veggie Pizza impleme tat . Veggie Pizza 
Plum Tomato Sauce, Mozzarella, Parmesan, based on region. Marinara Sauce, Reggiano, Mushrooms, 
Eggplant, Spinach, Black Olives Onions, Red Peppers 
Clam Pizza eg -_ Clam Pizza 


Plum Tomato Sauce, Mozzarella, Parmesan, Clams 


Marinara Sauce, Reggiano, Fresh Clams 


Pepperoni Pizza 
Plum Tomato Sauce, Mozzarella, Parmesan, 
Eggplant, Spinach, Black Olives, Pepperoni 


Pepperoni Pizza 


Marinara Sauce, Reggiano, Mushrooms, 
Onions, Red Peppers, Pepperoni 
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Families of ingredients... 


New York uses one set of 
ingredients and Chicago another. 
Given the popularity of Objectville 
Pizza it won’t be long before you 
also need to ship another set of 
regional ingredients to California, 
and what’s next? Seattle? 


For this to work, you are going to 
have to figure out how to handle 
families of ingredients. 


New York 


FreshClams 


MarinaraSauce ThinCrustDough 
ReggianoCheese 


Each family consists of a type of dough, 
a si of sauce, a type of cheese, and a 


the factory pattern 


Chicago 


FrozenClams 


seetville’s P 
All Objectil 
tomponents) ut each 


implementa jon 


PlumTomatoSauce 


wzzas are made 


of those Componen 


ThickCrustDough 
MozzarellaCheese 


C 


from the same 


different 


Ss. 


region has 4 


California 


BruschettaSauce 


Calamari 


VeryThinCrust 


seatood topping (along with a few more we ms 


haven't shown, like veggies and spices). 


GoatCheese 


ingredient Lamilies, with 


In total, these three regions make ally of ingredients: 


ath region impleme 


ting, a complete 
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ingredient factories 


Building the ingredient factories 


Now we’re going to build a factory to create our ingredients; the 
factory will be responsible for creating each ingredient in the 
ingredient family. In other words, the factory will need to create 
dough, sauce, cheese, and so on... You’ll see how we are going to 
handle the regional differences shortly. 


Let’s start by defining an interface for the factory that is going to 
create all our ingredients: 


public interface PizzaIngredientFactory { 


) 


(); . . define a 
| eoceath ingredient we . 


thod in ovr interface 


public Dough createDough 
public Sauce createSauce 
public Cheese createCheese(); ereate me 
public Veggies[] createVeggies(); 

public Pepperoni createPepperoni (); 

public Clams createClam() ; 


| ) 
Lots of new classes here, 
one per ingredient. 


If we'd had some Common “machinery” 
to implement in each instance of 
factory, we could have made this an 
abstract class instead... 


Here’s what we’re going to do: 


e Build a factory for each region. To do this, you'll create a subclass of 
PizzalngredientFactory that implements each create method 


2) Implement a set of ingredient classes to be used with the factory, like 
ReggianoCheese, RedPeppers, and ThickCrustDough. These classes can be 
shared among regions where appropriate. 


3) Then we still need to hook all this up by working our new ingredient 
factories into our old PizzaStore code. 
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Building the New York ingredient factory 


Okay, here’s the implementation for 
the New York ingredient factory. This 
factory specializes in Marinara sauce, 


Reggiano Cheese, Fresh Clams... The NY ingredient saa eee 


the interface for all ingredient 
Laetories 


public class NYPizzaIngredientFactory implements PizzaIngredientFactory { 


public Dough createDough() { 
return new ThinCrustDough (); 


| For each ingredient in 
e— ingredient Family, we Create 
public Sauce createSauce() { har aes 
return new MarinaraSauce(); Oa 


} 


public Cheese createCheese() { 
return new ReggianoCheese() ; 


} 


public Veggies[] createVeggies() { 


Veggies veggies[] = { new Garlic(), new Onion(), new Mushroom(), new RedPepper() }; 
return veggies; . i: 
} For veggies, we return an array 
; Veggies. Here we've hardeoded the 
public Pepperoni createPepperoni() { veggies. We could make this more 
See EE BSW phe Dee CODE none hs sophisticated, but that doesn't veally 
add anything +o learning the factory 
pattern, so we'll keep it simple. 
public Clams createClam() { 
return new FreshClams(); 
} 
) The best sliced pepperoni. This 
is shared between New York 
New York is on the coast; it and Chieago. Make sure you 
gets fresh clams. Chitago has use it on the next page when 
te settle for frozen. you get to implement the 
Chicago factory yourself 


youarehere > 147 


build a factory 


Gqdharpen your pencil 
IN Write the ChicagoPizzalngredientFactory. You can 
reference the classes below in your implementation: 


EggPlant 
Spinach 
ThickCrustDough 
BlackOlives SlicedPepperoni 
PlumTomatoSauce 


FrozenClam 
MozzarellaCheese | 
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Reworking the pizzas... 


We've got our factories all fired up and ready to produce quality ingredients; now we 
just need to rework our Pizzas so they only use factory-produced ingredients. We’ll 
start with our abstract Pizza class: 


public abstract class Pizza { : 
String name; Each pizza holds a set of ingredients 
that are used in its prepara lon. 
Dough dough; 
Sauce sauce; 
Veggies veggies[]; 


Meese sheace: We've now made the prepare method abstract. 
Pepperoni pepperoni; a This is where we ave going to collect the 
Clams clam; ingredients needed for the pizza, which of 


course will come from the ingredient factory. 


abstract void prepare(); 
void bake() { 


System.out.printin(“Bake for 25 minutes at 350”); 


void cut() { 
System.out.printlin(“Cutting the pizza into diagonal slices”); 


void box() { 
System.out.printin(“Place pizza in official PizzaStore box”); 


void setName(String name) { w 
this.name = name; qyR 

} E— Our other metho 

vo the exception of 


ds remain the same, with 
the prepare method. 


String getName() { 
return name; 


public String toString() { 
// code to print pizza here 
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Reworking the pizzas, continued... 


Now that you’ve got an abstract Pizza to work from, it’s time to create 
the New York and Chicago style Pizzas — only this time around they will 
get their ingredients straight from the factory. The franchisees’ days of 
skimping on ingredients are over! 


When we wrote the Factory Method code, we had a NYCheesePizza and 
a ChicagoCheesePizza class. If you look at the two classes, the only thing 
that differs is the use of regional ingredients. The pizzas are made just 
the same (dough + sauce + cheese). The same goes for the other pizzas: 
Veggie, Clam, and so on. They all follow the same preparation steps; they 
just have different ingredients. 


So, what you'll see is that we really don’t need two classes for each pizza; 
the ingredient factory is going to handle the regional differences for us. 
Here’s the Cheese Pizza: 


To make a pizza now) we need 


public class CheesePizza extends Pizza { 


vide the 
PizzaIngredientFactory ingredientFactory; : awe a a se 
ingredients: So eat : 

| : ) : : se 
public CheesePizza(PizzaIngredientFactory ingredientFactory) { class gets a factory ji “a 

this.ingredientFactory = ingredientFactory; . i ode s 
| stored in an anstance variable. 
void prepare() { 


System.out.printlin(“Preparing” + name) ; 
dough = ingredientFactory.createDough () 
sauce = ingredientFactory.createSauce () 
cheese = ingredientFactory.createCheese 


, 


: — Here's where the magic happens! 
(); 


The preparel) method steps through creating 
a theese pizza, and each time it needs an . 
ingredient, it asks the factory to produce it. 
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pe Code Up Close 


The Pizza code uses the factory it has been composed with to produce the ingredients used in the 
pizza. The ingredients produced depend on which factory we’re using. The Pizza class doesn’t care; 
it knows how to make pizzas. Now, it’s decoupled from the differences in regional ingredients and 


can be easily reused when there are factories for the Rockies, the Pacific Northwest, and beyond. 


ae sauce = ingredientFactory.createSauce () ; 


~~ 


We're setting the hod returns the sauce 


Pizza instance This is our ingredient factory. The ereateSaucel) = [f this is a NY 
Variable to vef, The Pizza doesn’t care which that is used in its region 4 marinara sauce: 
the specific . ‘“ factory is used, as long as it is ingredient factory, then we 9¢ 

€ 
used in this Pizza. an ingredient fattory. 


Let’s check out the ClamPizza as well: 


public class ClamPizza extends Pizza { 
PizzaIngredientFactory ingredientFactory; 


public ClamPizza(PizzaIngredientFactory ingredientFactory) { 
this.ingredientFactory = ingredientFactory; ClamPizza also stashes an 


ingredient factory. 


void prepare() { 
System.out.println(“Preparing” + name); 
dough = ingredientFactory.createDough () 
sauce = ingredientFactory.createSauce(); 
cheese = ingredientFactory.createCheese(); SN. To make a clam pizza, the ; 
clam = ingredientFactory.createClam(); << prepare method Collects the right 
} ingredients from its local factory: 


, 


If it’s a New York factory, 
the clams will be Lvesh; if it’s 
Chicago, they'll be frozen. 
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use the right ingredient factory 


Revisiting our pizza stores 


We’re almost there; we just need to make a quick trip to our 
franchise stores to make sure they are using the correct 
Pizzas. We also need to give them a reference to their local 
ingredient factories: 


public class NYPizzaStore extends PizzaStore { 


ol 
protected Pizza createPizza(String item) { be use Te yizzas 
Pizza pizza = null; for all NY y 


PizzaIngredientFactory ingredientFactory = 
new NYPizzaIngredientFactory (); 


if (item.equals(“cheese”)) { . 
| : | We now pass eath pizza the 
pizza = new CheesePizza(ingredientFactory) ; factory that should be used to 
pizza.setName (“New York Style Cheese Pizza”); produce its ingredients. 

} else if (item.equals(“veggie”)) { i 


Look back one page and make sure 
you understand how the pizza and 
the factory work together! 


pizza = new VeggiePizza(ingredientFactory) ; 
pizza.setName (“New York Style Veggie Pizza”); 


} else if (item.equals(“clam”)) { 


pizza = new ClamPizza(ingredientFactory) ; = \ 
pizza.setName (“New York Style Clam Pizza”); a— F 
or each type of Pizza 
) we 


} else if (item.equals(“pepperoni”)) { instantiate a new Pizza and give 
it the factory it needs to get 
pizza = new PepperoniPizza(ingredientFactory) ; its ingredients. 


pizza.setName (“New York Style Pepperoni Pizza”); 


} 


return pizza; 


RAIN 
POWER 


Compare this version of the createPizza() method 


to the one in the Factory Method implementation 
earlier in the chapter. 
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What have we done? 


That was quite a series of 
code changes; what exactly 
did we do? 


We provided a means 

of creating a family of 
ingredients for pizzas by 
introducing a new type of 
factory called an Abstract 
Factory. 


An Abstract Factory gives 
us an interface for creating 
a family of products. By 
writing code that uses this 
interface, we decouple our 
code from the actual factory 
that creates the products. 
That allows us to implement 
a variety of factories that 
produce products meant for 
different contexts - such as 
different regions, different 
operating systems, or 
different look and feels. 


Because our code is 
decoupled from the actual 
products, we can substitute 
different factories to get 
different behaviors (like 
getting marinara instead of 
plum tomatoes). 


the factory pattern 


An Abstract Factory provides an interface for 
a family of products. What's a family? In our 
case it’s all the things we need to make a pizza: 
dough, sauce, cheese, meats and veggies. 


New York Chicago 


From the abstract factory, we 
derive one or more concrete 
factories that produce the same 
products, but with different 
implementations. 


"Tea Store 


We then write our code so that it uses the 
factory to create products. By passing in 
a variety of factories, we get a variety of 
implementations of those products. But 
our client code stays the same. 


order some more pizza 


More pizza for Ethan and Joel... 


Behind 
Ethan and Joel can’t get enough Objectville Pizza! What they the Scenes 


don’t know is that now their orders are making use of the 
I'm stickin’ 
with Chicago. 


new ingredient factories. So now when they order... 


T'm still lovin’ NY Style. 


The first part of the order process hasn't changed at 
all. Let’s follow Ethan’s order again: 


Gb) First we need a NY PizzaStore: 


PizzaStore nyPizzaStore = new NYPizzaStore(); 


= Creates an instance of 


NYPizzaStore. ————_> 
7) 
2) WPiz7aS> 


Now that we have a store, we can take an order: 
nyPizzaStore.orderPizza (“cheese”) ; a 


oe the orderPizzal) method is called on 
the nyPizzaStore instance. 


cheese”) 


createPizz4 


€} The orderPizza() method first calls the cre- 
atePizza() method: 


Pizza pizza = createPizza(“cheese”) ; 
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From here things change, because we 


are using an ingredient factory Behind 
the Scenes 


4.) When the createPizza() method is called, that’s 
when our ingredient factory gets involved: 


; is chosen and 
The ingredient jal and then 


anstantiated in the Pi a 
na into the tonstructor of eath pizza 


poids 


= new CheesePizza(nyIngredientFactory) ; 


Pizza pizza = 
Sa Creates a instance of 


Pizza that is composed 


with the New York ———_> 
ingredient factory. 


tory 


oe 
roredien®” 


Next we need to prepare the pizza. Once the 


prepare() method is called, the factory is asked is 
to prepare ingredients: a 
QO, 
. erust 
void prepare() { ue 
dough = factory.createDough () ; 7-5 Marinara 
sauce = factory.createSauce(); 
cheese = factory.createCheese ( 


i 
YY Reggiano 


} 
For Ethan's pizza the New York 


ingredient faetory is used, and so We 
get the NY ingredients- 


Finally we have the prepared pizza in hand and the 
orderPizza() method bakes, cuts, and boxes the pizza. 
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abstract factory defined 


Abstract Factory Pattern defined 


We're adding yet another factory pattern to our pattern family, one that lets us create families 
of products. Let’s check out the official definition for this pattern: 


The Abstract Factory Pattern provides an interface 
for creating families of related or dependent objects 


without specifying their concrete classes. 


We've certainly seen that Abstract Factory allows a client to use an abstract interface to 
create a set of related products without knowing (or caring) about the concrete products that 
are actually produced. In this way, the client is decoupled from any of the specifics of the 
concrete products. Let’s look at the class diagram to see how this all holds together: 


The Client is written against the 
abstract factory and then Composed at 
cuntime with an actual factory. 


2 


Client 


The AbstractFactory defines the 
interface that all Conerete factories 
must implement, which Consists of a set 
of methods for producing products. 


This is the product 
family. Each contrete 
factory ean produce an 


<<interface>> entive set of products. <<interface>> 
AbstractFactory AbstractProductA 
CreateProductA() 7 
CreateProductB() 


ProductA1 


ProductA2 | 


<<interface>> 
AbstractProductB 


ConcreteFactory1 ConcreteFactory2 


CreateProductA() CreateProductA() 
CreateProductB() 


CreateProductB() 


( The conerete factories implement ) = 
different product families. To create a . 


product, the client uses one of these factories, ProductB2_ 
so it never has to instantiate a product object. 
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ProductB1 [ 


the factory pattern 


That’s a fairly complicated class The tlients of the Abstract 


diagram; let’s look at it all in terms of Factory are the two 

our PizzaStore: instances of our PizzaStore, 
NYPizzaStore and 
ChicagoStylePizzaS tore. 


NYPizzaStore 


createPizza() 


The abstract PizzalngredientFactory 
is the interface that defines how to 
make a family of related products 

— everything we need to make a pizza- 


<<interface>> 
Dough 


ThickCrustDough ThinCrustDough 


<<interface>> 
PizzalngredientFactory 


createDough() 
createSauce() <<interface>> 
createCheese() Sauce 
create Veggies() 
createPepperoni() Ba “ 
createClam() PlumTomatoSauce MarinaraSauce 
NYPizzalngredientFactory ChicagoPizzalngredientFactory <<interface>> 
createDough() createDough() Cheese 
createSauce() createSauce() 
createCheese() createCheese() os e 
createVeggies() createVeggies() Mozzarella Cheese ReggianoCheese 
createPepperoni() createPepperoni() 
createClam() createClam() 
<<interface>> 
Clams 
Le, 
The job of the conerete FrozenClams FreshClams 


pizza factories is to 

make pizza ingredients. 

Each factory knows 

how to create the right 

objects for their region. Each factory Produces a different q 
implementation for the family of products. 
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interview with factory patterns 


I noticed that each method in the 
Abstract Factory actually looks like a Factory 
Method (createDough(), createSauce(), etc.). 
Each method is declared abstract and the 
subclasses override it to create some 
object. Isn't that Factory Method? 


Is that a Factory Method Iurking inside the 
Abstract Factory? 


Good catch! Yes, often the methods of an Abstract Factory are 
implemented as factory methods. It makes sense, right? The job of an 
Abstract Factory is to define an interface for creating a set of products. 
Each method in that interface is responsible for creating a concrete 

J product, and we implement a subclass of the Abstract Factory to 

E supply those implementations. So, factory methods are a natural way to 
re implement your product methods in your abstract factories. 


Patterns Exposed 


This week’s interview: 
Factory Method and Abstract Factory, on each other 


HeadFirst: Wow, an interview with two patterns at once! This is a first for us. 

Factory Method: Yeah, I’m not so sure I like being lumped in with Abstract Factory, 

you know. Just because we’re both factory patterns doesn’t mean we shouldn’t get our own 
interviews. 

HeadFirst: Don’t be miffed, we wanted to interview you together so we could help clear up 
any confusion about who’s who for the readers. You do have similarities, and I’ve heard that 
people sometimes get you confused. 

Abstract Factory: It is true, there have been times I’ve been mistaken for Factory Method, 
and I know you've had similar issues, Factory Method. We’re both really good at decoupling 
applications from specific implementations; we just do it in different ways. So I can see why 
people might sometimes get us confused. 

Factory Method: Well, it still ticks me off. After all, I use classes to create and you use 
objects; that’s totally different! 
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HeadFirst: Can you explain more about that, Factory 
Method? 


Factory Method: Sure. Both Abstract Factory and 
I create objects — that’s our jobs. But I do it through 
inheritance... 


Abstract Factory: ...and I do it through object 


composition, 


Factory Method: Right. So that means, to create 
objects using Factory Method, you need to extend a class 
and override a factory method. 


HeadFirst: And that factory method does what? 


Factory Method: It creates objects, of course! I mean, 
the whole point of the Factory Method Pattern is that 
you're using a subclass to do your creation for you. In 
that way, clients only need to know the abstract type they 
are using, the subclass worries about the concrete type. 
So, in other words, I keep clients decoupled from the 
concrete types. 


Abstract Factory: And I do too, only I do it ina 
different way. 


HeadFirst: Go on, Abstract Factory... you said 
something about object composition? 


Abstract Factory: I provide an abstract type for 
creating a family of products. Subclasses of this type 
define how those products are produced. ‘To use the 
factory, you instantiate one and pass it into some code 
that is written against the abstract type. So, like Factory 
Method, my clients are decoupled from the actual 
concrete products they use. 


HeadFirst: Oh, I see, so another advantage is that you 
group together a set of related products. 


Abstract Factory: That’s right. 


HeadFirst: What happens if you need to extend that 
set of related products, to say add another one? Doesn’t 
that require changing your interface? 


Abstract Factory: That’s true; my interface has to 
change if new products are added, which I know people 
don’t like to do.... 


Factory Method: <snicker> 


Abstract Factory: What are you snickering at, 
Factory Method? 
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Factory Method: Oh, come on, that’s a big deal! 
Changing your interface means you have to go in and 
change the interface of every subclass! That sounds like a 
lot of work. 


Abstract Factory: Yeah, but I need a big interface 
because I am used to creating entire families of products. 
You're only creating one product, so you don’t really need 
a big interface, you just need one method. 


HeadFirst: Abstract Factory, I heard that you often use 
factory methods to implement your concrete factories? 


Abstract Factory: Yes, I’ll admit it, my concrete 
factories often implement a factory method to create 
their products. In my case, they are used purely to create 
products... 


Factory Method: ...while in my case I usually 
implement code in the abstract creator that makes use of 
the concrete types the subclasses create. 


HeadFirst: It sounds like you both are good at what 
you do. I’m sure people like having a choice; after all, 
factories are so useful, they’ll want to use them in all 
kinds of different situations. You both encapsulate 
object creation to keep applications loosely coupled 

and less dependent on implementations, which is really 
great, whether you’re using Factory Method or Abstract 
Factory. May I allow you each a parting word? 


Abstract Factory: Thanks. Remember me, Abstract 
Factory, and use me whenever you have families of 
products you need to create and you want to make sure 
your clients create products that belong together. 


Factory Method: And I’m Factory Method; use me to 
decouple your client code from the concrete classes you 
need to instantiate, or if you don’t know ahead of time 
all the concrete classes you are going to need. To use me, 
just subclass me and implement my factory method! 
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Factory Method and Abstract Factory compared 


PizzaStore is implemented as a Factory 
Method because we want te . able to 
' patra Lo eveate a product that varies by region. 
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New York Store 


NYPizzaStore ChicagoPizzaStore =, 
_7 createPizza() 7 createPizza() Chieago Store 
The Fattory Method 


The Factory Method 


This is the product of the 


PizzaStore. Clients only 
The NYPizzaStore subelass only 


rely on this abstract type: The ChicagaoPizzaS tore 
instantiates NY style pizzas. subelass instantiates only 
mA Chicago style pizzas. 
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NYStyleCheesePizza " 


ChicagoStyleCheesePizza) 
a instantiated 
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The ereatePizzal) method is parameterized by pizza 
type, so we Can return many types of pizza products. 
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the factory pattern 


Pizzalngredientractory is anne’ 
Abstract Factory because we need 


products (the ingredients). Each 


<<interface>> families ; : sina its own 
PizzalngredientFactory edhelass implements the ingredients using, 
createDough() . lies. 
al suppl 
Provides an abstract Fos createSauce() region rr 
no, a 
interface for creating 2 —-» ereateChesse( 
Lamil of oducts: ° create Veggies() 
ayore createPepperoni() 
createClam() Each contrete subclass 
eveates a family of products. 
N Ke 
> 
New York E 
NYPizzalngredientFactory ChicagoPizzalngredientFactory Chicago 

createDough() createDough() 

createSauce() createSauce() 

createCheese() createCheese() 

ce 

createVeggies() createVeggies() Methods to create produtts 

createPepperoni() createPepperoni() in an Abstract Fattory ae 

createClam() createClam() often implemented with a 

—_ a — 

for instante, the sublass ... or the type of elams. 


decides the type of dough... 


<<interface>> 
Dough 


ThickCrustDough ThinCrustDough 


\ 


<<interface>> 
Clams 


FrozenClams FreshClams 


Each ingredient 


represents a 


<<interface>> is <<interface>> 
Sauce product that Cheese 
produced by a 
. . Fattory Method 2 7 
PlumTomatoSauce MarinaraSauce in the Abstract Mozzarella Cheese ReggianoCheese 


Fattory- 


The product subclasses create parallel sets of product families. 
Here we have a New York ingredient family and a Chicago family. 
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your design foo!box 


Tools for your Design Toolbox 


In this chapter, we added two more tools to your 
toolbox: Factory Method and Abstract Factory. Both 
patterns encapsulate object creation and allow you to 
decouple your code from concrete types. 
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BULLET as 


All factories encapsulate object 
creation. 


Simple Factory, while not a bona 
fide design pattern, is a simple 
way to decouple your clients 
from concrete classes. 


Factory Method relies on 
inheritance: object creation is 
delegated to subclasses which 
implement the factory method to 
create objects. 


Abstract Factory relies on object 
composition: object creation 

is implemented in methods 
exposed in the factory interface. 


All factory patterns promote 
loose coupling by reducing the 
dependency of your application 
on concrete classes. 


The intent of Factory Method 
is to allow a class to defer 
instantiation to its subclasses. 


The intent of Abstract Factory 

is to create families of related 
objects without having to depend 
on their concrete classes. 


The Dependency Inversion 
Principle guides us to avoid 
dependencies on concrete types 
and to strive for abstractions. 


Factories are a powerful 
technique for coding to 
abstractions, not concrete 
classes 


the factory pattern 


It’s been a long chapter. Grab a slice of Pizza and relax while doing 
this crossword; all of the solution words are from this chapter. 


TT 


ram 
fa 


Across 
1. In Factory Method, each franchise is a 


4. In Factory Method, who decides which class 
to instantiate? 

6. Role of PizzaStore in Factory Method Pattern 
7. All New York Style Pizzas use this kind of 
cheese 

8. In Abstract Factory, each ingredient factory is 
a 

9. When you use new, you are programming to 
an 

11. createPizza() is a (two 
words) 

12. Joel likes this kind of pizza 

13. In Factory Method, the PizzaStore and the 
concrete Pizzas all depend on this abstraction 
14. When a class instantiates an object from a 
concrete class, it's on that object 
15. All factory patterns allow us to 

object creation 


PT Tt 


ial a 


PET TT EE ty yt 


Down 

2. We used in Simple Factory 
and Abstract Factory and inheritance in Factory 
Method 

3. Abstract Factory creates a of 
products 

5. Not a REAL factory pattern, but handy 
nonetheless 

10. Ethan likes this kind of pizza 
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exercise solutions 


Exereise solutions 


ce harpen our pencil 
“ y 


We've knocked out the NYPizzaStore; just two more to go and we'll be ready to franchise! 
Write the Chicago and California PizzaStore implementations here: 


Both of these stores are almost, exactly like oo New York 
C store... they just ereate different kinds of pizzas 


public class ChicagoPizzaStore extends PizzaStore { 
protected Pizza createPizza(String item) { 
if (item.equals(“cheese”)) { 
return new ChicagoStyleCheesePizza(); Q_ For the Chicago F274 
} else if (item.equals(“veggie”)) { store, we just have 
return new ChicagoStyleVeggiePizza(); make sure WE ereate 
} else if (item.equals(“clam”)) { oe Chieage style pizzas-- 
return new ChicagoStyleClamPizza(); Ze 
} else if (item.equals(“pepperoni”)) { 
return new ChicagoStylePepperoniPizza(); 
} else return null; 


public class CaliforniaPizzaStore extends PizzaStore { 
protected Pizza createPizza(String item) { 
if (item.equals(“cheese”)) { ; ; 
return new CaliforniaStyleCheesePizza(); ee and Lor the California 
} else if (item.equals(“veggie”)) { wzza store, WE ereave 
return new CaliforniaStyleVeggiePizza(); &, California style pizzas: 
} else if (item.equals(“clam”)) { 4 
return new CaliforniaStyleClamPizza(); b 
} else if (item.equals(“pepperoni”)) { 
return new CaliforniaStylePepperoniPizza(); 
} else return null; 
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Design Puzzle Solution 


We need another kind of pizza for those crazy Californians (crazy ina GOOD way of 


course). Draw another parallel set of classes that you’d need to add a new California 
region to our PizzaStore. 


PizzaStore 


createPizza() 


Here's everything You need te 


Te aga store, 
add a California ra a 
the tonerete Pizz4 store Class 


a and the California style pizzas 


ChicagoPizzaStore CaliforniaPizzaStore 
createPizza() 


orderPizza() 


NYPizzaStore 


createPizza() 


createPizza() 


NYStyleCheesePizza " ChicagoStyleCheesePizza) CaliforniaStyleCheesePizza 
NYStylePepperoniPizza " ChicagoStylePepperoniPizza CaliforniaStylePepperoniPizza " 
= NYStyleClamPizza " = ChicagoStyleClamPizza " = CaliforniaStyleClamPizza " 
= | NYStyleVeggiePizza = | ChicagoStyleVeggiePizza | CaliforniaStyleVeggiePizza 


—I 


Okay, now write the five silliest things you can think of to put on a pizza. Then, you'll 
be ready to go into business making pizza in California! 


Here are our 


suggestions Mashed Potatoes with Roasted Garlic 
BBQ Sauce 


Artichoke Hearts 
MéM's 
Peanuts 
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A very dependent PizzaStore 


eatery your pencil 
De Let’s pretend you've never heard of an OO factory. Here’s a version of the PizzaStore 
that doesn’t use a factory; make a count of the number of concrete pizza objects this 


class is dependent on. If you added California style pizzas to this PizzaStore, how many 
objects would it be dependent on then? 


public class DependentPizzaStore { 


public Pizza createPizza(String style, String type) { 


Pizza pizza = null; 
if (style.equals (“NY”) ) 
if (type.equals(“cheese”)) { 
pizza = new NYStyleCheesePizza(); 
} Stee if (eype-eauels (vegqee ')) { Handles all the NY 
- — — Meaty heed ee tea style pizzas 
al ype.equals(“clam”)) { 
pizza = new NYStyleClamPizza(); 
} else if (type.equals(“pepperoni”)) { 
pizza = new NYStylePepperoniPizza(); 
} 
} else if (style.equals(“Chicago”)) { 
if (type.equals(“cheese”)) { 
pizza = new ChicagoStyleCheesePizza(); Handles all the 
} else if (type.equals (“veggie”)) { Chicago style 
pizza = new ChicagoStyleVeggiePizza(); . 
} else if (type.equals(“clam”)) { aad 
pizza = new ChicagoStyleClamPizza(); 
} else if (type.equals (“pepperoni”)) { 
pizza = new ChicagoStylePepperoniPizza(); 
} 
} else 


System.out.println(“Error: invalid type of pizza”); 
return null; 

} 

pizza.prepare(); 

pizza.bake(); 

pizza.cut(); 

pizza.box(); 

return pizza; 


You can write 
your answers here: @ number 12 number Wt 


Lh California te 
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G harpen our pencil 
4 y 


Go ahead and write the ChicagoPizzaIngredientFactory; you can reference the 
classes below in your implementation: 


public class ChicagoPizzaIngredientFactory 
implements PizzaIngredientFactory 


public Dough createDough() { 
return new ThickCrustDough () ; 


public Sauce createSauce() { 
return new PlumTomatoSauce () ; 


public Cheese createCheese() { 
return new MozzarellaCheese(); 


public Veggies[] createVeggies() { 
Veggies veggies[] = { new BlackOlives(), 

new Spinach(), 
new Eggplant() }; 


return veggies; 


{ 


public Pepperoni createPepperoni () 
return new SlicedPepperoni (); 


public Clams createClam() { 
return new FrozenClams(); 


EggPlant 


ThickCrustDough 


Spinach ’ 


SlicedPepperoni 


BlackOlives 


PlumTomatoSauce 


FrozenClams 


MozzarellaCheese 
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crossword puzzle solution 


SOK Puzzle Solution 
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5 the Singleton Pattern 


=k 
+ One of a Kind Objects + 


T tell ya she’s ONE OF A 
KIND. Look at the lines, 
the curves, the body, 

the headlights! 


You talkin’ to me or the car? Oh, 
and when can I get my oven mitt 
back? 


Our next stop is the Singleton Pattern, our ticket to creating one- 
of-a-kind objects for which there is only one instance. You might be 
happy to know that of all patterns, the Singleton is the simplest in terms of its class diagram; 
in fact, the diagram holds just a single class! But don’t get too comfortable; despite its 
simplicity from a class design perspective, we are going to encounter quite a few bumps and 


potholes in its implementation. So buckle up. 


this is a new chapter 169 


one and only one 


What is this? An 
entire chapter about how to 

instantiate just 
ONE OBJECT! 


That's one and ONLY 
ONE object. 


Developer: What use is that? 


Guru: There are many objects we only need one of: thread pools, caches, dialog boxes, objects that handle 
preferences and registry settings, objects used for logging, and objects that act as device drivers to devices 
like printers and graphics cards. In fact, for many of these types of objects, if we were to instantiate 

more than one we'd run into all sorts of problems like incorrect program behavior, overuse of resources, or 
inconsistent results. 


Developer: Okay, so maybe there are classes that should only be instantiated once, but do I need a whole 
chapter for this? Can't I just do this by convention or by global variables? You know, like in Java, I could do it 
with a static variable. 


Guru: In many ways, the Singleton Pattern is a convention for ensuring one and only one object is instantiated 
for agiven class. If you've got a better one, the world would like to hear about it; but remember, like all 
patterns, the Singleton Pattern is a time-tested method for ensuring only one object gets created. The 
Singleton Pattern also gives us a global point of access, just like a global variable, but without the downsides. 


Developer: What downsides? 

Guru: Well, here's one example: if you assign an object to a global variable, then that object might be created 
when your application begins. Right? What if this object is resource intensive and your application never ends 
up using it? As you will see, with the Singleton Pattern, we can create our objects only when they are needed. 
Developer: This still doesn't seem like it should be so difficult. 

Guru: If you've got a good handle on static class variables and methods as well as access modifiers, it's not. 
But, in either case, it is interesting to see how a Singleton works, and, as simple as it sounds, Singleton code is 


hard to get right. Just ask yourself: how do I prevent more than one object from being instantiated? It's not 
so obvious, is it? 
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The Little Singleton 


the singleton pattern 


A small Socratic exercise in the style of The Little Lisper 


How would you create a single object? 


And, what if another object wanted to create a 
MyObject? Could it call new on MyObject again? 


So as long as we have a class, can we always 
instantiate it one or more times? 


And if not? 


Hmm, interesting. 


Did you know you could do this? 


public MyClass { 


private MyClass() {} 


What does it mean? 


Well, is there ANY object that could use 
the private constructor? 


new MyObject (); 


Yes, of course. 


Yes. Well, only if it’s a public class. 


Well, if it’s not a public class, only classes in the same 
package can instantiate it. But they can still instantiate 
it more than once. 


No, I'd never thought of it, but I guess it makes 
sense because it is a legal definition. 


I suppose it is a class that can’t be instantiated 
because it has a private constructor. 


Hmm, I think the code in MyClass is the only 
code that could call it. But that doesn’t make 
much sense. 
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creating a singleton 


Why not ? 


Okay. It was just a thought. 


What does this mean? 


public MyClass { 


public static MyClass getInstance() 


} 


Why did you use MyClass, instead of 


some object name? 


Very interesting. What if we put things together. 


Now can I instantiate a MyClass? 


public MyClass { 


private MyClass() {} 


public static MyClass getInstance() 
return new MyClass(); 


So, now can you think of a second way to instantiate 


an object? 


Can you finish the code so that only ONE instance 
of MyClass is ever created? 
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Because I'd have to have an instance of the 
class to call it, but I can’t have an instance 
because no other class can instantiate it. It’s 
a chicken and egg problem: I can use the 
constructor from an object of type MyClass, 
but I can never instantiate that object because 
no other object can use “new MyClass()”. 


MyClass is a class with a static method. We can 


call the static method like this: 


MyClass.getInstance(); 


Well, getInstance() is a static method; in other 
words, it is a GLASS method. You need to use 
the class name to reference a static method. 


Wow, you sure can. 


MyClass.getInstance(); 


Yes, I think so... 


(You'll find the code on the next page.) 


the singleton pattern 


Dissecting the classic Singleton 
Pattern implementation 


Watch it! 
Let’s rename MyClass \pave 2 dae : is 
ow 
to Singleton. yee ko “ be If you're just 
’ apskante flipping through 
public class Singleton { one cynohetor” the book, don't 
private static Singleton uniquelInstance; class blindly type in this 


code, you'll see it 
has a few issues 
later in the chapter. 


// other useful instance variables here 


a Our constructor is 
declared privates 

only Singleton can 
instantiate this lass! 


private Singleton() {} 


The getlnstance() 
method gives us a way 
to instantiate the ¢lass 
and also to return an 
instance of it. 


of Course, Singleton is 
4 normal ¢lass; it has 
other usefy instance 
variables and methods. 


JX Code Up Clase 
\f uniquelnstance is null, then we 


uniquelnstance holds our ONE haven't created the instance yet 

instante; remember, it is a eee err a 

statie variable. a instantiate Singleton through its 

private constructor and assign 
( it to unigque|nstance. Note that 
if (uniqueInstance == null) { if we never need the instante, it 
uniqueInstance = new MyClass(); ugha gets created; this is lazy 
} instantiation. 
a N 


return uniqueInstance; 


\f unigquelnstance wasnt null, 
then it was previously created. 
We just fall through to the 
By the time we hit this code, we return statement. 


have an instance and we return it. 
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Patterns Exposed 
This week’s interview: 
Confessions of a Singleton 


HeadFirst: Today we are pleased to bring you an interview with a Singleton object. Why don’t 
you begin by telling us a bit about yourself. 


Singleton: Well, I’m totally unique; there is just one of me! 
HeadFirst: One? 


Singleton: Yes, one. I’m based on the Singleton Pattern, which assures that at any one time 
there is only one instance of me. 


HeadFirst: Isn’t that sort of a waste? Someone took the time to develop a full-blown class and 
now all we can get is one object out of it? 


Singleton: Not at all! ‘There is power in ONE. Let’s say you have an object that contains 
registry settings. You don’t want multiple copies of that object and its values running around 
— that would lead to chaos. By using an object like me you can assure that every object in your 
application is making use of the same global resource. 


HeadFirst: Tell us more... 


Singleton: Oh, I’m good for all kinds of things. Being single sometimes has its advantages you 
know. Pm often used to manage pools of resources, like connection or thread pools. 


HeadFirst: Still, only one of your kind? That sounds lonely. 


Singleton: Because there’s only one of me, I do keep busy, but it would be nice if more 
developers knew me — many developers run into bugs because they have multiple copies of 
objects floating around they’re not even aware of. 


HeadFirst: So, if we may ask, how do you know there is only one of you? Can’t anyone with a 
new operator create a “new you”? 


Singleton: Nope! I’m truly unique. 
HeadFirst: Well, do developers swear an oath not to instantiate you more than once? 


Singleton: Of course not. The truth be told... well, this is getting kind of personal but... I 
have no public constructor. 


HeadFirst: NO PUBLIC CONSTRUCTOR! Oh, sorry, no public constructor? 
Singleton: That’s right. My constructor is declared private. 
HeadFirst: How does that work? How do you EVER get instantiated? 


Singleton: You see, to get a hold of a Singleton object, you don’t instantiate one, you just ask 
for an instance. So my class has a static method called getInstance(). Call that, and I'll show up 
at once, ready to work. In fact, I may already be helping other objects when you request me. 


HeadFirst: Well, Mr. Singleton, there seems to be a lot under your covers to make all this work. 
Thanks for revealing yourself and we hope to speak with you again soon! 
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The Chocolate Factory 


Everyone knows that all modern chocolate factories have computer controlled 
chocolate boilers. The job of the boiler is to take in chocolate and milk, bring them 
to a boil, and then pass them on to the next phase of making chocolate bars. 


Here’s the controller class for Ghoc-O-Holic, Inc.’s industrial strength Chocolate 
Boiler. Check out the code; you'll notice they’ve tried to be very careful to ensure 
that bad things don’t happen, like draining 500 gallons of unboiled mixture, or 
filling the boiler when it’s already full, or boiling an empty boiler! 


public class ChocolateBoiler { 
private boolean empty; 
private boolean boiled; 


public ChocolateBoiler() { This code is only started 
empty = true; i when the boiler is empty! 
boiled = false; 


} 


‘ler it must be 
id fi To fill the boiler it mu 
ae pee ) { a a ee and, once ts os . set 

empty = false; the empty and boiled +la9s- 


boiled = false; 
// fill the boiler with a milk/chocolate mixture 


} 


public void drain() { ——, 
an To drain the boiler, it must be full 


(!isEmpty() && isBoiled()) { _ 
// drain the boiled milk and chocolate (non empty) and also boiled. Once it is 
empty = true; drained we set empty back to true. 


} 


public void boil() { 
if (!isEmpty() && !isBoiled()) { To beil . : 
// bring the contents to a poi rar sp the boiler 
boiled = true; ; oe ard not already 
boiled. Once it’s boiled we set 
the boiled flag to true. 


public boolean isEmpty() { 
return empty; 


} 
public boolean isBoiled() { 


return boiled; 


} 
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chocolate boiler singleton 


eSB RAN 
PQwee 


Choc-O-Holic has done a decent job of ensuring bad things don’t happen, don’t ya think? Then 
again, you probably suspect that if two ChocolateBoiler instances get loose, some very bad 
things can happen. 


How might things go wrong if more than one instance of ChocolateBoiler is created in an 
application? 


by turning it into a singleton? 


G Sharper your pencil Can you help Choc-O-Holic improve their ChocolateBoiler class 
aN 
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public class ChocolateBoiler { 
private boolean empty; 
private boolean boiled; 


pO 


[| chocolateBoiler () { 


empty = true; 
boiled = false; 


public void fill() { 
if (isEmpty()) { 
empty = false; 
boiled = false; 
// fill the boiler with a milk/chocolate mixture 


} 
} 


// vest of ChocolateBoiler code... 


the singleton pattern 


Singleton Pattern defined 


Now that you’ve got the classic implementation of Singleton 
in your head, it’s time to sit back, enjoy a bar of chocolate, 
and check out the finer points of the Singleton Pattern. 


Let’s start with the concise definition of the pattern: 


The Singleton Pattern ensures a class has only one 


instance, and provides a global point of access to it. 


No big surprises there. But, let’s break it down a bit more: 


=" What’s really going on here? We’re taking a class and letting it manage a 
single instance of itself. We’re also preventing any other class from creating a 


new instance on its own. To get an instance, you’ve got to go through the class 
itself. 


= We're also providing a global access point to the instance: whenever you 
need an instance, just query the class and it will hand you back the single 
instance. As you’ve seen, we can implement this so that the Singleton is created 
in a lazy manner, which is especially important for resource intensive objects. 


Okay, let’s check out the class diagram: 


ie diss kids The uniquelnstance 
bnstan el) me ekhod 8° class variable holds our 
The geen’ ats a class ™ kno d only instance 
vey means | ess Unt € one and only in 
vi convener ‘ code using of Singleton. 
tae Te pnyerere OU) Thak’s ee Singleton 
— mgerins ae val variable, bv static uniquelnstance 
singe eeessin 3 % stantiation 
easy 3 a ¢ ‘ue \azy // Other useful Singleton data... 
encX" 
we get 0 Cinole tor: static getInstance() 
Grom the 59 
// Other useful Singleton methods... 


i i Sinaleton 
class implementing the Singleton 
irs is move than a Singleton; it 
isa general purpose tlass with 1 
own set of data and methods. 
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threads are a problem 


Hershey. mh 
Houston; we have a problem... 


It looks like the Chocolate Boiler has let us down; despite 
the fact we improved the code using Classic Singleton, 
somehow the ChocolateBoiler’s fill() method was able 

to start filling the boiler even though a batch of milk and 
chocolate was already boiling! That’s 500 gallons of spilled 
milk (and chocolate)! What happened!? 


We don't know what happened! The 
new Singleton code was running fine. The only 
thing we can think of is that we just added some 
optimizations to the Chocolate Boiler Controller 
that makes use of multiple threads. 


Could the addition of threads have caused 
this? Isn’t it the case that once we’ve set 
the uniquelnstance variable to the sole 
instance of ChocolateBoiler, all calls to 
getinstance() should return the same 
instance? Right? 
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BE the JVM 
_ We have two threads, each executing this code. Your job is to play the JVM 
(. and determine whether there is a case in which two threads might get ahold 
of different boiler objects. Hint: 
A you really just need to look at the ChocolateBoiler boiler = 


| sequence of operations ChocolateBoiler.getInstance(); 
in the getInstance() ean 
method and the value of ee ; 
unjqueInstance to see 
how they might overlap. 
Use the code Magnets to help 


you study how the code might interleave to create two hoiler objects. 


Make sure you check your answer on 
page 188 before turning the page! 


(uniqueInstance == null) { 


uniqueInstance = 
new ChocolateBoiler(); Thread 
Two || uniqueInstance 
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multithreading and singleton 


Dealing with multithreading 


Our multithreading woes are almost trivially fixed by making 
getinstance() a synchronized method: 
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public class Singleton { 


Good point, and it’s actually a little worse than you make out: the only 
time synchronization is relevant is the first time through this method. In 
other words, once we’ve set the uniqueInstance variable to an instance 
of Singleton, we have no further need to synchronize this method. After 
the first time through, synchronization is totally unneeded overhead! 


Chapter 


nchronized keyword te 


private static Singleton uniqueInstance; By anne i 7 Roos Teead is 
getinstance’, Ler the 

// other useful instance variables here wait its barn before it Can ene 
vwethod. That is, no two threa f Y 

private Singleton() {} enter the method at the same time: 


public static synchronized Singleton getInstance() { 
if (uniqueInstance == null) { 
uniqueInstance = new Singleton (); 


} 


return uniquelInstance; 


// other useful methods here 


I agree this 
fixes the problem. 
But synchronization 
is expensive; is this an 
issue? 


1S) 
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Can we improve multithreading? 


For most Java applications, we obviously need to ensure that the Singleton works in the presence 
of multiple threads. But, it looks fairly expensive to synchronize the getInstance() method, so what 
do we do? 


Well, we have a few options... 


1. Do nothing if the performance of getlnstancel() isn’t critical to 
your application 


That’s right; if callmg the getInstance() method isn’t causing substantial overhead for your 
application, forget about it. Synchronizing getInstance() is straightforward and effective. Just keep 
in mind that synchronizing a method can decrease performance by a factor of 100, so if a high 
traffic part of your code begins using getInstance(), you may have to reconsider. 


2. Move to an eagerly created instance rather than a lazily 
created one 


If your application always creates and uses an instance of the Singleton or the overhead of 
creation and runtime aspects of the Singleton are not onerous, you may want to create your 
Singleton eagerly, like this: 


————, 


public class Singleton { Go ahead and tvéake 
private static Singleton uniqueInstance = new Singleton (); instance of Si lek ‘ 
MAleton in 


a stati initializer. This 


private Singleton() {} . 
Code is guaranteed to be 
public static Singleton getInstance() { thread safe! 
return uniquelInstance; 
} <———______ We've allready got an it 
} instance, $0 jyst Os 


Using this approach, we rely on the JVM to create the unique instance of the Singleton when 
the class 1s loaded. The JVM guarantees that the instance will be created before any thread 
accesses the static uniqueInstance variable. 


double-checked /ocking 


3, Use “double-checked locking” to reduce the use of 
synchronization in getinstance() 


With double-checked locking, we first check to see if an instance 1s created, and if not, ‘THEN we 


synchronize. This way, we only synchronize the first time through, just what we want. 


Let’s check out the code: 


public class Singleton { 
private Giacadstsearic Singleton uniquelInstance; 


private Singleton() {} 


ae Cheek for an instance and 
public static Singleton getInstance() { if Dee isn't one, enter a 
if (uniqueInstance == null) { 


; f synchronized block. 
synchronized (Singleton.class) { 
if (uniqueInstance == null) { 


Note we only synchronize 
uniqueInstance = new Singleton(); 
} 


the first time through! 
} 


} 


return uniqueInstance; 


| Once in the block, check again and 


it still null, create an instance. 


+ The volatile keyword ensures that multiple threads 
handle the uniquelnstance variable correctly when it 
is being initialized to the Singleton instance. 


If performance 1s an issue in your use of the getInstance() method then this method of 
implementing the Singleton can drastically reduce the overhead. 
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Double-checked locking doesn’t 
Wateh st! work in Java 1.4 or earlier! 


Unfortunately, in Java version 1.4 and earlier, many r 
JVMs contain implementations of the volatile — ; 
that allow improper synchronization anne a e 
| ther than Java 9, 
cking. If you must use a JVM other 
sorsek net methods of implementing your Singleton. 
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Meanwhile, back at the Chocolate Factory... 


While we’ve been off diagnosing the multithreading problems, the chocolate boiler 
has been cleaned up and 1s ready to go. But first, we have to fix the multithreading 
problems. We have a few solutions at hand, each with different tradeoffs, so which 
solution are we going to employ? 


@esharpen your pencil 
ere yeep 


For each solution, describe its applicability to the problem of fixing the Chocolate 
Boiler code: 


Synchronize the getInstance() method: 


Use eager instantiation: 


Double-checked locking: 


Congratulations! 


At this point, the Chocolate Factory is a happy customer and Choc-O-Holic was glad to have some 
expertise applied to their boiler code. No matter which multithreading solution you applied, the boiler 
should be in good shape with no more mishaps. Congratulations. You’ve not only managed to escape 
500lbs of hot chocolate in this chapter, but you’ve been through all the potential problems of the Singleton. 
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q&a about singleto 


Q: For such a simple pattern 
consisting of only one class, 
Singletons sure seem to have some 
problems. 


: Well, we warned you up 
front! But don’t let the problems 
discourage you; while implementing 
Singletons correctly can be tricky, 
after reading this chapter you are now 
well informed on the techniques for 
creating Singletons and should use 
them wherever you need to control 
the number of instances you are 
creating. 


Relax 


DEE Ghestions 


* Can’tI just create a class in 
which all methods and variables are 
defined as static? Wouldn’t that be 
the same as a Singleton? 


A: Yes, if your class is self- 
contained and doesn’t depend on 


complex initialization. However, 
because of the way static 
initializations are handled in Java, 
this can get very messy, especially if 
multiple classes are involved. Often 
this scenario can result in subtle, 
hard to find bugs involving order 

of initialization. Unless there is a 
compelling need to implement your 
“singleton” this way, it is far better to 
stay in the object world. 


: What about class loaders? 
| heard there is a chance that two 
class loaders could each end up with 
their own instance of Singleton. 


2 Yes, that is true as each class 
loader defines a namespace. If you 
have two or more classloaders, you 
can load the same class multiple times 
(once in each classloader). Now, if 
that class happens to be a Singleton, 
then since we have more than one 
version of the class, we also have more 
than one instance of the Singleton. So, 
if you are using multiple classloaders 
and Singletons, be careful. One way 
around this problem is to specify the 
classloader yourself. 


Rumors of Singletons being eaten by the garbage 
collectors are greatly exaggerated 


Prior to Java 1.2, a bug in the garbage collector allowed Singletons 
to be prematurely collected if there was no global reference to them. In other 
words, you could create a Singleton and if the only reference to the Singleton 
was in the Singleton itself, it would be collected and destroyed by the garbage 
collector. This leads to confusing bugs because after the Singleton is 

“collected,” the next call to getinstance() produced a shiny new Singleton. In 
many applications, this can cause confusing behavior as state is mysteriously 
reset to initial values or things like network connections are reset. 


Since Java 1.2 this bug has been fixed and a global reference is no longer 
required. If you are, for some reason, still using a pre-Java 1.2 JVM, then be 
aware of this issue, otherwise, you can sleep well knowing your Singletons 
won't be prematurely collected. 


184 


Q: I’ve always been taught that 
a class should do one thing and one 
thing only. For a class to do two 
things is considered bad OO design. 
Isn’t a Singleton violating this? 


A: You would be referring to 

the “One Class, One Responsibility” 
principle, and yes, you are correct, the 
Singleton is not only responsible for 
managing its one instance (and pro- 
viding global access), it is also respon- 
sible for whatever its main role is in 
your application. So, certainly it can 
be argued it is taking on two respon- 
sibilities. Nevertheless, it isn’t hard to 
see that there is utility in a class man- 
aging its own instance; it certainly 
makes the overall design simpler. In 
addition, many developers are familiar 
with the Singleton pattern as it is in 
wide use. That said, some developers 
do feel the need to abstract out the 
Singleton functionality. 


Q: | wanted to subclass my 
Singleton code, but | ran into 
problems. Is it okay to subclass a 
Singleton? 


A: One problem with subclassing 
Singleton is that the constructor 

is private. You can’t extend a class 
with a private constructor. So, the 
first thing you'll have to do is change 
your constructor so that it’s public 

or protected. But then, it’s not really 
a Singleton anymore, because other 
classes can instantiate it. 


If you do change your constructor, 
there's another issue. The 
implementation of Singleton is based 
on a static variable, so if youdoa 
straightforward subclass, all of your 
derived classes will share the same 
instance variable. This is probably 
not what you had in mind. So, for 
subclassing to work, implementing 
registry of sorts is required in the base 
class. 


Before implementing such a scheme, 
you should ask yourself what you 

are really gaining from subclassing 

a Singleton. Like most patterns, the 
Singleton is not necessarily meant to 
be a solution that can fit into a library. 
In addition, the Singleton code is 
trivial to add to any existing class. 
Last, if you are using a large number 
of Singletons in your application, 
you should take a hard look at your 
design. Singletons are meant to be 
used sparingly. 
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Q: I still don’t totally understand 
why global variables are worse than 
a Singleton. 


A: In Java, global variables are 
basically static references to objects. 
There are a couple of disadvantages 
to using global variables in this 
manner. We've already mentioned 
one: the issue of lazy versus eager 
instantiation. But we need to keep 

in mind the intent of the pattern: to 
ensure only one instance of a class 
exists and to provide global access. A 
global variable can provide the latter, 
but not the former. Global variables 
also tend to encourage developers 
to pollute the namespace with lots 
of global references to small objects. 
Singletons don't encourage this in 
the same way, but can be abused 
nonetheless. 
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Tools for your Design Toolbox 


You’ve now added another pattern to your 
toolbox. Singleton gives you another method 
of creating objects - in this case, unique 
objects. 


OO Principles 
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As you've seen, despite its apparent simplicity, there are a lot of details 
involved in the Singleton’s implementation. Arter reading, this chapter, 
though, you are ready to go out, and use Singleton in the wild. 
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The Singleton Pattern ensures 
you have at most one instance 
of a class in your application. 


The Singleton Pattern also 
provides a global access point 
to that instance. 


Java’s implementation of the 
Singleton Pattern makes use 
of a private constructor, a static 
method combined with a static 
variable. 


Examine your performance 
and resource constraints and 
carefully choose an appropriate 
Singleton implementation for 
multithreaded applications 

(and we should consider all 
applications multithreaded!). 


Beware of the double-checked 
locking implementation; it is not 
thread-safe in versions before 
Java 2, version 5. 


Be careful if you are using 
multiple class loaders; this 
could defeat the Singleton 
implementation and result in 
multiple instances. 


If you are using a JVM earlier 
than 1.2, you'll need to create a 
registry of Singletons to defeat 
the garbage collector. 
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Across 

1. It was "one of a kind" 

2. Added to chocolate in the boiler 

8. An incorrect implementation caused this to 

overflow 

10. Singleton provides a single instance and 

(three words) 

12. Flawed multithreading approach if not using 

Java 1.5 

13. Chocolate capital of the US 

14. One advantage over global variables: 
creation 

15. Company that produces boilers 

16. To totally defeat the new constructor, we 

have to declare the constructor 
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Sit back, open that case of chocolate that you were sent for solving 
the multithreading problem, and have some downtime working on 
this little crossword puzzle; all of the solution words are from this 


Ele 


11 


ee 


Down 

1. Multiple can cause problems 
3. A Singleton is a class that manages an 
instance of 

4. If you don't need to worry about lazy 
instantiation, you can create your instance 


5. Prior to 1.2, this can eat your Singletons (two 
words) 

6. The Singleton was embarassed it had no 
public 

7. The classic implementation doesn't handle 
this 

9. Singleton ensures only one of these exist 
11. The Singleton Pattern has one 
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uniqueInstance = 
new ChocolateBoiler(); 
return ae 


uniqueInstance = 


new ChocolateBoiler(); 


Thead Thead Value of 
One Two || uniqueInstance 
public static ChocolateBoiler null 
getInstance() { 
public static ChocolateBoiler AWTT 
getInstance() { 
if (uniqueInstance == null) { | 
a : = null 
if (uniqueInstance == null) { 


mle 


<object 1> 


<object1> 


<object2 


return uniqueInstance; 


<object 2> 


Can you help Choc-O-Holic improve their ChocolateBoiler class 


harpen your pencil 
oP } : P by turning it into a singleton? 


public class ChocolateBoiler { 
private boolean empty; 
private boolean boiled; 


private static ChocolateBoiler uniqueInstance; 


ChocolateBoiler() { 


empty = true; 
boiled = false; 


public static ChocolateBoiler getInstance() { 
if (uniqueInstance == null) { 
uniqueInstance = new ChocolateBoiler (); 
} 


return uniqueInstance; 


public void fill() { 
if (isEmpty()) { 
empty = false; 
boiled = false; 
// fill the boiler with a milk/chocolate mixture 


} 
// vest of ChocolateBoiler code... 
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Uh oh, this doesn't 
look good! 


Two different 
objects are 
returned! We have 
two ChotolateBoiler 
instances!!! 


the singleton pattern 


Exereise solutions 


ore your pencil 


For each solution, describe its applicability to the problem of fixing the Chocolate 
Boiler code: 


Synchronize the getInstance() method: 


A straightforward technique that is quaranteed to work. We don't seem to have an 


performance tonterns with the chotolate boiler, so this would be a good choice. 


Use eager instantiation: 


We are always going to instantiate the chocolate boiler in our code, so statically initializing the 


instance would cause no Concerns. This solution would work as well as the synchronized method, 


although perhaps be less obvious to a developer familar with the standard pattern. 


Double checked locking: 


Given we have no performance toncerns, double—checked locking seems like overkill. In addition, we'd 


have to ensure that we are running at least Java 5. 
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In this chapter, we take encapsulation to a whole new level: 
we’re going to encapsulate method invocation. That's right, by 
encapsulating method invocation, we can crystallize pieces of computation so that the 
object invoking the computation doesn’t need to worry about how to do things, it just uses 
our crystallized method to get it done. We can also do some wickedly smart things with 
these encapsulated method invocations, like save them away for logging or reuse them to 


implement undo in our code. 
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Home Zutomation or Bust. inc. 
1221 industrial Avenue, Suite 2000 


Chapter 6 


Future City, TL 62914 


Greetings! 


I recently received a demo and briefing from Johnny 
Hurricane, CEO of Weather-O-Rama, on their new 
expandable weather station. Ihave to say, I was so 
impressed with the software architecture that ’'d like to 
ask you to design the API for our new Home Automation 
Remote Control. In return for your services we’d be happy 
to handsomely reward you with stock options in Home 
Automation or Bust, Inc. 


I’m enclosing a prototype of our ground-breaking remote 
control for your perusal. The remote control features seven 
programmable slots (each can be assigned toa different 
household device) along with corresponding on/off buttons 
for each. The remote also has a global undo button. 


Tm also enclosing a set of Java classes on CD-R that were 
created by various vendors to control home automation 
devices such as lights, fans, hot tubs, audio equipment, and 
other similar controllable appliances. 


We'd like you to create an API for programming the remote 
go that each slot can be assigned to control a device or set of 
devices. Note that it is important that we be able to control 
the current devices on the disc, and also any future devices 
that the vendors may supply. 


Given the work you did on the Weather-O-Rama weather 
station, we know you'll doa great job on our remote control! 


We look forward to seeing your design. 


Sincerely, 


Ets TP homposn 


Bill “X-10” Thompson, CEO 
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Free hardware! Let’s check out the Remote Control... 


There are “on” and “off” 


buttons for each of the 
seven slots. 
We { 
‘am. 
ve aot seven slots to prog j 
eae atherent device each s 


and control 


Get your Sharpie out and 


wirite your device names here- 


it via the buttons: 


These two buttons are 
used to control the 
household device stored ; 
slot one... ° 
~~ and these two Control 
the household device 

red in slot two... 


- and SO on. 


Here’s the global “undo” button that 
undoes the last button pressed. 
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vendor classes from home automation 


Taking a look at the vendor classes 


Check out the vendor classes on the CD-R. These should give 
you some idea of the interfaces of the objects we need to control 
from the remote. 


ApplianceControl 


on() 
CeilingLight off() 
setCd() 
setDvd() 
setRadio 
dim() TV " 
setVolume() 
OutdoorLight on) FaucetControl 
on() off() openValue() 
off() setInputChannel() closeValue() 
setVolume() 
CeilingFan Hottub 
high() circulate() 
GardenLight medium() di cad oe 
: low() up() jetsOff() 

setDuskTime() off() down() setTemperaturet() 

setDawnTime() getSpeed() stop() 

manualOn() isis Thermostat 

manualOff() light setTemperature() 

Sprinkler SecurityControl 
waterOn() arm() 
waterOff() disarm() 


It looks like we have quite a set of classes here, and not a lot of 


industry effort to come up with a set of common interfaces. Not 


only that, it sounds like we can expect more of these classes in the 
future. Designing a remote control API is going to be interesting. 
Let’s get on to the design. 
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Cubicle Conversation 


Your teammates are already discussing how to design the remote control API... 


Well, we've got another design to do. 
My first observation is that we've got a 

simple remote with on and off buttons but 
a set of vendor classes that are quite 


Mary: Yes, I thought we’d see a bunch of classes with on() 
and offf) methods, but here we’ve got methods like dim(), 
set lemperature(), set Volume(), setDirection(). 


Sue: Not only that, it sounds like we can expect more vendor 
classes in the future with just as diverse methods. 


Mary: | think it’s important we view this as a separation of 
concerns: the remote should know how to interpret button presses 
and make requests, but it shouldn’t know a lot about home 
automation or how to turn on a hot tub. 


Sue: Sounds like good design. But if the remote is dumb and 
just knows how to make generic requests, how do we design the 
remote so that it can invoke an action that, say, turns on a light or 
opens a garage door? 


Mary: [’m not sure, but we don’t want the remote to have to 
know the specifics of the vendor classes. 


Sue: What do you mean? 


Mary: We don’t want the remote to consist of a set of if 
statements, like “if slot] == Light, then light.on(), else if slot] = 
Hottub then hottubjetsOn()”. We know that is a bad design. 


Sue: I agree. Whenever a new vendor class comes out, we’d have 
to go in and modify the code, potentially creating bugs and more 
work for ourselves! 
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Hey, I couldn't help 
overhearing. Since Chapter 1 
I've been boning up on Design 

Patterns. There's a pattern 
called “Command Pattern" I think 
might help. 


Mary: Yeah? Tell us more. 


Joe: The Command Pattern allows you to decouple the requester of an action 
from the object that actually performs the action. So, here the requester would be 
the remote control and the object that performs the action would be an instance 
of one of your vendor classes. 


Sue: How is that possible? How can we decouple them? After all, when I press a 
button, the remote has to turn on a light. 


Joe: You can do that by introducing “command objects” into your design. A 
command object encapsulates a request to do something (like turn on a light) on 
a specific object (say, the living room light object). So, if we store a command 
object for each button, when the button is pressed we ask the command object to 
do some work. The remote doesn’t have any idea what the work is, it just has a 
command object that knows how to talk to the right object to get the work done. 
So, you see, the remote is decoupled from the light object! 


Sue: This certainly sounds like it’s going in the right direction. 
Mary: Still, ?m having a hard time wrapping my head around the pattern. 


Joe: Given that the objects are so decoupled, it’s a little difficult to picture how the 
pattern actually works. 


Mary: Let me see if I at least have the right idea: using this pattern we, could 
create an API in which these command objects can be loaded into button 

slots, allowing the remote code to stay very simple. And, the command objects 
encapsulate how to do a home automation task along with the object that needs 
to do it. 


Joe: Yes, I think so. [ also think this pattern can help you with that Undo button, 
but I haven’t studied that part yet. 


Mary: This sounds really encouraging, but I think I have a bit of work to do to 
really “get” the pattern. 


Sue: Me too. 


the command pattern 


Meanwhile, back at the Diner..., 
or ps ‘ 
A brief introduction to the Command Pattern 


As Joe said, it is a little hard to understand the Command Pattern by just hearing 
its description. But don’t fear, we have some friends ready to help: 
remember our friendly diner from Chapter 1? It’s been a while since we 
visited Alice, Flo, and the short-order cook, but we’ve got good reason 
for returning (well, beyond the food and great conversation): the diner is 


Objectville Diner 
o- =e 


ed 


going to help us understand the Command Pattern. —— 


ateewer rer * 


So, let’s take a short detour back to the diner and study the interactions 
between the customers, the waitress, the orders and the short-order ma 
cook. Through these interactions, you’re going to understand the 

objects involved in the Command Pattern and also get a feel for how 


the decoupling works. After that, we’re going to knock out that remote 
control API. 


Wish you were eve. 


Checking in at the Objectville Diner... 


Okay, we all know how the Diner operates: 


2] The Waitress 
takes the Order, 


You, the Customer, places it on the 

give the Waitress order counter 

your Order. and says “Order 
up!” 


3] The Short-Order Cook prepares your meal 
from the Order. 


the diner 


Let’s study the interaction in a little more detail... 


«and given this Diner is in Objectville, let’s think 
about the object and method calls involved, too! 


The Order tonsists of gn order 
slip gnd the eustomer = 
vtems that are written on 1 


T'll have a Burger 
with Cheese and a 
Malt Shake. 


The customer knows 
what he wants and 
treates an order. 


The Waitress takes the Order, 
gets around to 
method to begi 


j and when she 
it, she calls its orderUp() 
n the Order's Preparation. 


The Short Ovder 
Cook follows the 
instructions of 
the Order and 
Produces the meal. 


makeBurger(), makeShake() 
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The Objectville Diner roles and responsibilities 


An Order Slip encapsulates a request to prepare a meal. 


Think of the Order Slip as an object, an object that ats, 


as a request to prepare a meal. Like any object, it can be 
passed around — from the Waitress to the order counter, or to the 
next Waitress taking over her shift. It has an interface that consists 
of only one method, orderUp(), that encapsulates the actions 
needed to prepare the meal. It also has a reference to the object 
that needs to prepare it (in our case, the Cook). It’s encapsulated 


in that the Waitress doesn’t have to know what’s in the order o) 
or even who prepares the meal; she only needs to pass the slip Okay, « 
through the order window and call “Order up!” aie ‘: ee life 8 Waitress 
: is on th Ould Prob 
i but this is pp nj order Sih aly 
; 7 . . iS Objeed,. 'P and wh 
The Waitress’s job is to take Order Slips and Jeet. work wi ro ia 
ere 


invoke the orderUp() method on them. 


The Waitress has it easy: take an order from the customer, 


continue helping customers until she makes it back to the 


Don't ask me to cook, 
T just take orders and 


order counter, then invoke the orderUp() method to have 
yell “Order up!" 


the meal prepared. As we've already discussed, in Objectville, the 
Waitress really isn’t worried about what’s on the order or who 1s going to 
prepare it; she just knows order slips have an orderUp() method she can 
call to get the job done. 


Now, throughout the day, the Waitress’s takeOrder() method gets 
parameterized with different order slips from different customers, but 
that doesn’t phase her; she knows all Order slips support the orderUp() 
method and she can call orderUp() any time she needs a meal prepared. 


The Short Order Cook has the knowledge 
required to prepare the meal. 


You 
can definitely say 
the waitress and I are 
decoupled. She's not 
even my type! 


The Short Order Cook is the object that really knows 
how to prepare meals. Once the Waitress has invoked 

the orderUp() method; the Short Order Cook takes over and 
implements all the methods that are needed to create meals. 
Notice the Waitress and the Cook are totally decoupled: the 
Waitress has Order Slips that encapsulate the details of the 
meal; she just calls a method on each order to get it prepared. | 
Likewise, the Cook gets his instructions from the Order Slip; he | 
never needs to directly communicate with the Waitress. > 


the diner is a mode! for command pattern 


Okay, we have a 

Diner with a Waitress who is 
decoupled from the Cook by an 
Order Slip, so what? Get to 
the point! 


WAL 


ero. 


Patience, we’re getting there... 


Think of the Diner as a model for an OO design pattern that allows 
us to separate an object making a request from the objects that 
receive and execute those requests. For instance, in our remote 
control API, we need to separate the code that gets invoked when 
we press a button from the objects of the vendor-specific classes 
that carry out those requests. What if each slot of the remote held 
an object like the Diner’s order slip object? Then, when a button is 
pressed, we could just call the equivalent of the “orderUp()” method 
on this object and have the lights turn on without the remote 
knowing the details of how to make those things happen or what 
objects are making them happen. 


Now, let’s switch gears a bit and map all this Diner talk to the 
Command Pattern... 


Before we move on, spend some time studying 
the diagram two pages back along with Diner 
roles and responsibilities until you think you’ve 
got a handle on the Objectville Diner objects and 
relationships. Once you’ve done that, get ready 
to nail the Command Pattern! 


the command pattern 


From the Diner to the Command Pattern 


Okay, we’ve spent enough time in the Objectville Diner that we know all the 
personalities and their responsibilities quite well. Now we’re going rework the 
Diner diagram to reflect the Command Pattern. You'll see that all the players 
are the same; only the names have changed. 


The actions and the 


Receiver are bound together 
in the Command object. 


x 5 4 
The tommand object public eet ae 
iver. : 
5 one method, seeeiver action? 0} 


provide 


execute), that encapsulates 
the actions and can be ealled 
to invoke the attions on the 


Receiver: 


The elient is responsible for ereating 
the Command object. The Command 
object tonsists of a set of attions 


on a receiver. 


create 
Command 


Commar® Object () 
The client calls setCommand() on = 
an Invoker object and passes it the Fr Client 


command object, where it gets stored 
until it is needed. = 3) 


Loading the Invoker 


e The client creates a 


setCommand () command object. 


2] The client does a 
setCommand() to store 
the command object in 
the invoker. 


3] Later... the client asks 


the invoker to execute 
which vesults the command. Note: 


as you'll see later in 
the chapter, once the 
command is loaded into 
the invoker, it may be 
used and discarded, or 
it may remain and be 


action1(), action2() Receive used many times. 


in the actions 
being invoked on 


the Receiver. 


f action1() 
® action2 () 
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who what? 


+ &F 


+ 
WUuUS BOES WHAT? 


Match the diner objects and methods with the corresponding names from the 
Command Pattern. 


Diner Command Pattern 


Waitress Command 
Short Order Cook execute() 
orderUpO Client 
Order Invoker 


Customer Receiver 


takeOrder() setCommand() 
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Our first command object 


Isn’t it about time we build our first command object? Let’s go ahead and write 
some code for the remote control. While we haven’t figured out how to design the 
remote control API yet, building a few things from the bottom up may help us... 


Implementing the Command interface 


First things first: all command objects implement the same interface, which 
consists of one method. In the Diner we called this method orderUp(); however, 
we typically just use the name execute(). 


Here’s the Command interface: 


public interface Command { 


Simple. All . 
piste old eesceted sh. > am. P we need is one method called exetute(). 
} 


Implementing a Command to turn a light on 


Now, let’s say you want to implement a command for turning a light on. 
Referring to our set of vendor classes, the Light class has two methods: on() 
and off). Here’s how you can implement this as a command: 


This is a Command, so we need to 
implement the Command interface. 


public class LightOnCommand implements Command { 


Light light; The constructor is passed the specific 


nibi ie Ligipontommend tight Digney { ~ that this Command is going 


: i = li : ontrol — say the living room light 
} Sone regee gee i S ae in the Tight ae 
variable. When execute gets called, this 
public void execute() { is the light object that is going to be 
eee the Receiver of the request: 
} The execute method Calls the 


on() method on the receiving 
object, which is the light we 
are controlling, 


Now that you’ve got a LightOnCommand class, let’s see if we can put it to use... 
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Using the command object 


Okay, let’s make things simple: say we’ve got a remote control with only one 
button and corresponding slot to hold a device to control: 


We have one slot to hold our tommand, 
: | 
public class SimpleRemoteControl { 7 a wey - tedl tiie 


Command slot; 


i led 
public void setCommand(Command command) { to control _ ge a, 
slot = command; multiple times i the ¢lien 
} this code wanted to change the 
behavior of the remote button. 


{ 
Sy This method is ¢alled when the 


button is Pressed. All we do is take 
the current command bound +0 the 
slot and call its execute() method. 


We have a method for setting 


public SimpleRemoteControl() {} the dewmand the slot is going, 


public void buttonWasPressed() 
slot.execute(); 


} 


Creating a simple test to use the Remote Control 


Here’s just a bit of code to test out the sumple remote control. Let’s take a look and 
we'll point out how the pieces match the Command Pattern diagram: 


_speak. 
—_ This is our Client in Command Pattern—spe 


The remote is our Invoker) 

public class RemoteControlTest { 
public static void main(String[] 
SimpleRemoteControl 
Light light = new Light(); 


args) { 


remote.setCommand(lightOn) ; 
remote.buttonWasPressed(); ») 


. Here, pass the command 
to the [nvoker. 


find then we simulate the 
button being pressed. 


ttere’s the output of 5 
running this test eodel 
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remote = new SimpleRemoteControl (); 


LightOnCommand lightOn = new LightOnCommand (light) ; 


it will be passed 
ane object that can 


be used to make requests: 
Now we ereate a Light 


object, this will be the 
Reteiver of the request. 


on Here, create a Command and 


pass the Receiver to it. 


File Edit_Window Help DinerFoodYum 


Sjava RemoteControlTest 


Light is On 


% 


the command pattern 


G harpen our pencil 
u y 


Okay, it’s time for you to implement the 
GarageDoorOpenCommand class. First, supply the code for 
the class below. You’ll need the GarageDoor class diagram. ——~. 


GarageDoor 


up() 
down() 
stop() 
lightOn() 
) 


public class GarageDoorOpenCommand Car 
ig 


implements Command { 


aS aie ‘sede ee 


Now that you’ve got your class, what is the output of the following 
code? (Hint: the GarageDoor up() method prints out “Garage Door is 
Open” when it is complete.) 


public class RemoteControlTest { 

public static void main(String[] args) { 
SimpleRemoteControl remote = new SimpleRemoteControl (); 
Light light = new Light(); 
GarageDoor garageDoor = new GarageDoor () ; 
LightOnCommand lightOn = new LightOnCommand (light) ; 
GarageDoorOpenCommand garageOpen = 

new GarageDoorOpenCommand (garageDoor) ; 


remote.setCommand(lightoOn) ; 
remote.buttonWasPressed(); 
remote.setCommand (garageOpen) ; 
remote.buttonWasPressed(); 


ojava RemoteControlTest 


command pattern defined 


The Command Pattern defined 


You’ve done your time in the Objectville Diner, you’ve partly 
implemented the remote control API, and in the process you’ve 
got a fairly good picture of how the classes and objects interact in 
the Command Pattern. Now we’re going to define the Command 
Pattern and nail down all the details. 


Let’s start with its official definition: 


The Command Pattern encapsulates a request as an 
object, thereby letting you parameterize other objects 


with different requests, queue or log requests, and support 
undoable operations. 


Let’s step through this. We know that a command object 
encapsulates a request by binding together a set of actions on a 
specific receiver. To achieve this, it packages the actions and the 
receiver up into an object that exposes just one method, execute(). 
When called, execute() causes the actions to be invoked on the 
receiver. From the outside, no other objects really know what 
actions get performed on what receiver; they just know that if they 
call the execute() method, their request will be serviced. 


We've also seen a couple examples of parameterizing an olject with 
acommand. Back at the diner, the Waitress was parameterized 
with multiple orders throughout the day. In the simple remote 
control, we first loaded the button slot with a “light on” command 
and then later replaced it with a “garage door open” command. 
Like the Waitress, your remote slot didn’t care what command 
object it had, as long as it implemented the Command interface. 


What we haven’t encountered yet is using commands to 
implement queues and logs and support undo operations. Don’t worry, 
those are pretty straightforward extensions of the basic Command 
Pattern and we will get to them soon. We can also easily support 
what’s known as the Meta Command Pattern once we have the 
basics in place. The Meta Command Pattern allows you to create 
macros of commands so that you can execute multiple commands 
at once. 
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An entapsulated request: 


Recéwes 


execute() { 
receiver.action(); 


An invoker — for instance one 
slot of the remote — Can be 
parameterized with different 


requests. 


The Command Pattern defined: 
the class diagram 


The Invoker holds 
a Command and at 
some point asks the 


lient is responsible for command to carr 
. ConbrebeCommand and out a request by : 
sna its Receiver: alling its exeeute() 
setting | ( method. 
Client 


Invoker 


setCommand() 


Receiver 


action() 


The Receiver knows how to m 
the work needed to carry out the 
request. Any Class can act as a 


oii The ConereteCommand a 
and a Receiver. The |nvok 


exetutel) and 
calling one or more attio 


iQ RAWN 
POWER 


request and the receiver of the request? 


How does the design of the Command Pattern support the decoupling of the invoker of a 


the command pattern 


Command declares an interface for all commands. hs ou 
already know, a Command is invoked through its execute 
method, whith asks a receiver to perform an action. 
You'll also notice this interface has an undol) method, 
which we'll Cover a bit later in the chapter. 


J 


<<interface>> 
Command 


execute() 
undo() 


The execute 
method invokes 
the attion(s) 
on the receiver 
needed to fulfill 
the vequest- 


ConcreteCommand 


execute() Spe reisin ese cieee ae sof 
undo() 


public void execute() { 
receiver.action() 


} 


efines a binding between an action 
ev makes a request by calling 


the ContreteCommand carries it out by 


ns on the Receiver: 
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where do we b 
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Okay, I think I've got a good feel 
for the Command Pattern now. Great 
tip Joe, I think we are going to look like 
superstars after finishing of f the 
Remote Control APT. 


Mary: Me too. So where do we begin? 


Sue: Like we did in the SimpleRemote, we need to provide a way 
to assign commands to slots. In our case we have seven slots, each 
with an “on” and “off” button. So we might assign commands to 
the remote something like this: 

onCommands[0] = onCommand; 

offCommands[0] = offCommand; 


and so on for each of the seven command slots. 


Mary: That makes sense, except for the Light objects. How does 
the remote know the living room from the kitchen light? 


Sue: Ah, that’s just it, it doesn’t! The remote doesn’t know 
anything but how to call execute() on the corresponding 
command object when a button is pressed. 


Mary: Yeah, I sorta got that, but in the implementation, how do 
we make sure the right objects are turning on and off the right 
devices? 


Sue: When we create the commands to be loaded into the 
remote, we create one LightCommand that is bound to the living 
room light object and another that is bound to the kitchen light 
object. Remember, the receiver of the request gets bound to 

the command it’s encapsulated in. So, by the time the button 

is pressed, no one cares which light is which, the right thing just 
happens when the execute() method is called. 


Mary: | think I’ve got it. Let’s implement the remote and I think 
this will get clearer! 


Sue: Sounds good. Let’s give it a shot... 


the command pattern 


Assigning Commands to slots 


So we have a plan: We’re going to assign each slot to a command in 
the remote control. This makes the remote control our iwvoker. When 
a button is pressed the execute() method is going to be called on the 
corresponding command, which results in actions being invoked on the 
receiver (like lights, ceiling fans, stereos). 


(I) Bath slot gets a Command. 


(2) When the button is pressed, the exeeute() 
method is Called on the corresponding command. 


Ayes 
OO; 
ro ok S rOF FCA 
S @, 
Frage Bae net 
—) ©. 
Sere ing roo 
g 
~S 
e Doe 


We'll worry about the 
remaining slots in a bit. 


(3) In the exeeute() method actions 
are invoked on the receiver. 


The Invoker ar 


Stereo 
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Implementing the Remote Control 


This time around the remote is going te 
wT iicimana |) chbomasnesy: On and off commands, which 


: handle seven 
Command[] onCommands; 2 Sai ela in converte ding, avvays. 


Command[] offCommands; 


public RemoteControl() { In the constructor all we need to do is 
onCommands = new Command[7]; C _ instantiate and initialize the on and off 
offCommands = new Command[7]; a arrays. 


Command noCommand = new NoCommand() ; 

for (int 2 = 07 1 < 7; att) { 
onCommands[i] = noCommand; 
offCommands[i] = noCommand; 


public void setCommand(int slot, Command onCommand, Command offCommand) { 

Sob Cie nes TeieG), = eue nena “TL The setCommand() method takes a slot position 

Gree ene ea epee —,. and an On and OFF command to be stored in that 
slot. [t puts these Commands in the on and off 


public void onButtonWasPushed(int slot) { arrays for later use. 


onCommands [slot] .execute(); 
} When an On or OFF button is 
KR pressed, the hardware takes 
public void offButtonWasPushed(int slot) { com tare of calling the corresponding 
offCommands [slot] .execute () ; methods onButtonWasPushed() or 
} of fButtonWasPushed(). 


public String toString() { 
StringBuffer stringBuff = new StringBuffer (); 
stringBuff. append (“\n------ Remote Control ------- Nn’ yis 
for (int i = 0; i < onCommands.length; i++) { 
stringBuff.append(“[slot “ + i+ “] “ + onCommands[i].getClass() .getName () 
+ “ + of fCommands[i].getClass().getName() + “\n”); 
} 
return stringBuff.toString(); 
} We've overwritten toString() to print out each slot and its 
} Corresponding command. You'll see us use this when we test the 
remote control. 
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Implementing the Commands 


Well, we’ve already gotten our feet wet implementing the LightOnCommand for 
the SimpleRemoteControl. We can plug that same code in here and everything 
works beautifully. Off commands are no different; in fact the LightOffCommand 
looks like this: 


public class LightOffCommand implements Command { 
Light light; 


public LightOffCommand(Light light) { 
this.light = light; 
} 


public void execute() { 
light.off(); 


the command pattern 


The LightO£fCommand works exactly 
the same way as the LightOnCommand, 
except that we are binding the receiver 


} —— toa different action: the off) method. 


Let’s try something a little more challenging; how about writing on and off 
commands for the Stereo? Okay, off is easy, we just bind the Stereo to the off{) 
method in the StereoOffGommand. On 1s a little more complicated; let’s say we 
want to write a StereoOnWithGDCommand... 


public class StereoOnWithCDCommand implements Command { 
Stereo stereo; 


public StereoOnWithCDCommand (Stereo stereo) { 
this.stereo = stereo; 


Stereo 


on() 
off() 
setCd() 
setDvd() 
setRadio() 
setVolume() 


Just like the LightOnCommand, we get 


—~ passed the instance of the stereo we are 


Goins, to be eontrolling and we store it in 


public void execute() { 
stereo.on(); 
stereo.setCD(); 
stereo.setVolume (11); 


a 


a local instance variable. 


To ¢arry out this request, we need to call three 
methods on the stereo: first, turn it on, then set 
it to play the CD, and finally set the volume to |]. 


Why II? Well, it’s better than 10, vight? 


Not too bad. Take a look at the rest of the vendor classes; by now, you can definitely 
knock out the rest of the Command classes we need for those. 
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Putting the Remote Control through its paces 


Our job with the remote is pretty much done; all we need to do is run some tests and 
get some documentation together to describe the API. Home Automation or Bust, 
Inc. sure is going to be impressed, don’t ya think? We’ve managed to come up with 
a design that is going to allow them to produce a remote that is easy to maintain 

and they’re going to have no trouble convincing the vendors to write some simple 
command classes in the future since they are so easy to write. 


Let’s get to testing this code! 


public class RemoteLoader { 


public static void main(String[] args) { 
RemoteControl remoteControl = new RemoteControl(); 


Light livingRoomLight = new Light (“Living Room”); Create all the devices in 
Light kitchenLight = new Light (“Kitchen”) ; their proper lotations. 
CeilingFan ceilingFan= new CeilingFan(“Living Room”) ; 

GarageDoor garageDoor = new GarageDoor(‘”); 

Stereo stereo = new Stereo(“Living Room”) ; 


LightOnCommand livingRoomLightOn = 

new LightOnCommand(livingRoomLight) ; . 
LightOffCommand livingRoomLightOff = Create all the Light Command 
new LightOffCommand(livingRoomLight) ; objects 

LightOnCommand kitchenLightOn = 

new LightOnCommand(kitchenLight) ; 

LightOffCommand kitchenLightOff = 

new LightOffCommand(kitchenLight) ; 


CeilingFanOnCommand ceilingFanOn = Create the On and oft 
new CeilingFanOnCommand (ceilingFan) ; Lor the ceiling, ‘an. 
CeilingFanOffCommand ceilingFanOff = 
new CeilingFanOffCommand (ceilingFan) ; 


GarageDoorUpCommand garageDoorUp = 
new GarageDoorUpCommand (garageDoor) ; Create the Up and Down 
GarageDoorDownCommand garageDoorDown = commands for the Garage 
new GarageDoorDownCommand (garageDoor) ; 


StereoOnWithCDCommand stereoOnWithCD = 
new StereoOnWithCDCommand (stereo) ; Create the stereo On 
StereoOffCommand stereoOff = and OLL commands. 
new StereoOffCommand (stereo) ; 
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setCommand 
setCommand 
setCommand 
setCommand 


trol. 
trol. 
trol. 
ExXOoL,, 


remoteCon 
remoteCon 
remoteCon 


(0 
(1 
(2, 
remoteCon (3 


System.ou 


, livingRoomLightOn, 
, kitchenLightOn, 
ceilingFanOn, 
, stereoOnWithCD, 


t.println(remoteControl) ; 


the command pattern 


livingRoomLightOff) ; 
kitchenLightOff) ; 
ceilingFanOff) ; 
stereoOff); 


Now that we've got 
all our Commands, we 
can load them into 
the remote slots. 


_> 


remoteControl.onButtonWasPushed (0) ; 

remoteControl.offButtonWasPushed (0) ; Here’s where we use our toStrina() 
remoteControl.onButtonWasPushed(1); method to print eath remote il and 
remoteControl.offButtonWasPushed (1) ; the command that it is assi d to 
remoteControl.onButtonWasPushed (2); Igne . 
remoteControl.offButtonWasPushed (2) ; 

remoteControl.onButtonWasPushed (3); 

remoteControl.offButtonWasPushed (3) ; 


= All right, we are ready to roll! 
Now, we step through each slot 
and push its On and OFF button. 


Now, let’s check out the execution of our remote control test... 


File Edit Window Help CommandsGetThingsDone 


java RemoteLoader 
Remote Control 
headfirst .command. 
headfirst.command. 
headfirst.command. 
headfirst .command. 
headfirst .command. 
headfirst.command. 
headfirst.command. 


remote . 
remote. 
remote. 
remote. 
remote’. 
remote. 
remote . 


NoCommand 
NoCommand 
NoCommand 


Living Room light is on 

Living Room light is off 

Kitchen Itoght ie on 

Kitchen light is off 

Living Room ceiling fan is on high 
Living Room ceiling fan is off 

Living Room stereo is on 

Living Room stereo is set for CD input 
Living Room Stereo volume set to 11 
Living Room stereo is off 


LightOnCommand 
LightOnCommand 
CeilingFanOnCommand 
StereoOnWithCDCommand 


headfirst. 
headfirst. 
headfirst. 
headfirst. 
headfirst. 
headfirst. 
headfirst. 


(i 


OFF Slots 


remote. 
remote. 
remote. 
remote. 
remote. 
remote. 
remote. 


command. 
command. 
command. 
command. 
command. 
command. 
command. 


LightOffCommand 
LightOffCommand 
CeilingFanOffCommand 
StereoOffCommand 
NoCommand 

NoCommand 

NoCommand 


On slots 


<——__ Our commands in action! Remember, the output 
from each device comes from the vendor classes. 


For instance, when a light object is turned on it 
prints Living Room light is on.” 
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null object 


Wait a second, what 
is with that NoCommand that 
is loaded in slots four through six? 
Trying to pull a fast one? 


Good catch. We did sneak a little something in there. In the remote 
control, we didn’t want to check to see if a command was loaded every 
time we referenced a slot. For instance, in the onButtonWasPushed() 
method, we would need code like this: 


public void onButtonWasPushed(int slot) { 
if (onCommands[slot] != null) { 
onCommands [slot].execute(); 


} 
So, how do we get around that? Implement a command that does nothing! 


public class NoCommand implements Command { 
public void execute() { } 


Then, in our RemoteControl constructor, we assign every slot a 
NoCommand object by default and we know we'll always have some 
command to call in each slot. 


Command noCommand = new NoCommand() ; 

for (int i = 0; i < 7; itt) { 
onCommands[i] = noCommand; 
offCommands[i] = noCommand; 


So in the output of our test run, you are seeing slots that haven't been 
assigned to a command, other than the default NoGommand object 
which we assigned when we created the RemoteControl. 


The NoCommand object is an example of a null object. A null object is useful 
when you don't have a meaningful object to return, and yet you want to remove 
the responsibility for handling null from the client. For instance, in our remote 
control we didn’t have a meaningful object to assign to each slot out of the box, 
so we provided a NoCommand object that acts as a surrogate and does nothing 
when its execute method is called. 


You'll find uses for Null Objects in conjunction with many Design Patterns and 
sometimes you'll even see Null Object listed as a Design Pattern. 


the command pattern 


Time to write that documentation... 


Remote Control API Design for Home Automation or Bust, Inc., 


We are pleased to present you with the following design and application programming interface for your Home 


Automation Remote Control. 


Our primary design goal was to keep the remote control code as simple as possible so that 


it doesn’t require changes as new vendor classes are produced. To this end we have employed the Command Pattern to 
logically decouple the RemoteControl class from the Vendor Classes. We believe this will reduce the cost of producing 
the remote as well as drastically reduce your ongoing maintenance costs. 


The following class diagram provides an overview of our design: 


The RemoteLoader creates a 
number of Command Objects 
that are loaded into the slots 
of the Remote Control. Each 
command object encapsulates 
a request of a home 
automation device. 


The RemoteControl manages a set of Command 
objects, one per button. When a button is 
pressed, the corresponding ButtonWasPushed() 
method is called, which invokes the execute() 
method on the command. That is the full extent 
of the remote’s knowledge of the classes it’s 
invoking as the Command object decouples the 
remote from the classes doing the actual home- 
automation work. 


All RemoteControl commands 
implement the Command 
interface, which consists of one 


RemoteLoader 


method: execute(). Commands 
encapsulate a set of actions 

ona specific vendor class. The 
remote invokes these actions by 
calling the execute() method. 


<<interface>> 
Command 


RemoteControl 


onCommands 
offCommands 


execute() 


setCommand() 
onButtonWasPushed() 
offButtonWasPushed() 


public void execute() { 
light .on(): 


the Light class as an example. 


The Vendor Classes are used to perform 
the actual home-automation work of 
controlling devices. Here, we are using 


} 
public void execute() { 
light.off () 
} 


Using the Command Interface, each action that can be 
invoked by pressing a button on the remote is implemented 


with a simple Command object. The Command Object 
holds a reference to an object that is an instance of a Vendor 
Class and implements an execute method that calls one 

or more methods on that object. Here we show two such 
classes that turn a light on and off, respectively. 
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don’t forget undo 


Great job; it looks like 
you've come up with a terrific design, 
but aren't you forgetting one little thing 
the customer asked for? 

LIKE THE UNDO BUTTON?! 


Whoops! We almost forgot... luckily, once we 
have our basic Command classes, undo is easy 
to add. Let’s step through adding undo to our 
commands and to the remote control... 


What are we doing? 


Okay, we need to add functionality to support the undo button on the remote. It works like 
this: say the Living Room Light is off and you press the on button on the remote. Obviously 
the light turns on. Now if you press the undo button then the last action will be reversed — in 
this case the light will turn off. Before we get into more complex examples, let’s get the light 
working with the undo button: 


ay When commands support undo, they have an undo() method that mirrors the execute() 
method. Whatever execute() last did, undo() reverses. So, before we can add undo to our 
commands, we need to add an undo() method to the Command interface: 


public interface Command { 
public void execute(); 
public void undo(); 


QR _ Here’s the new undo() method. 


That was simple enough. 


Now, let’s dive into the Light command and implement the undo() method. 
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Let’s start with the LightOnCommand: if the LightOnCommand’s execute() method 
was called, then the on() method was last called. We know that undo() needs to do the 
opposite of this by calling the off() method. 


public class LightOnCommand implements Command { 
Light light; 


public LightOnCommand(Light light) { 
this.light = light; 
} 


public void execute() { 
light.on(); 
} 


Q 
public void undo() { ane light on, 8° 
light.off(); moe) simply TS 
to) 
} FR Ye light bath off. 


Piece of cake! Now for the LightOffGCommand. Here the undo() method just 
needs to call the Light’s on() method. 


public class LightOffCommand implements Command { 
Light light; 


public LightOffCommand(Light light) { 
this.light = light; 
} 


public void execute() { 
light.off(); 
} 


public void undo() { And here 
light.on(); Lyens Une 
} A— 


Could this be any easier? Okay, we aren’t done yet; we need to work a little 


support into the Remote Control to handle tracking the last button pressed 
and the undo button press. 
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5] To add support for the undo button we only have to make a few small changes to the Remote 


Con 


trol class. Here’s how we’re going to do it: we'll add a new instance variable to track the 


last command invoked; then, whenever the undo button is pressed, we retrieve that command 


and 


invoke its undo() method. 


public class RemoteControlWithUndo { 
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ican ae acerca | This is where we'll stash the last Command 


Command[] offCommands; 
Command undoCommand; Pa executed for the undo button. 


public RemoteControlWithUndo() { 
onCommands = new Command[7]; 
offCommands = new Command[7]; 


Command noCommand = new NoCommand() ; 
for(int i=0;i<7;i++) 


onCommands[i] = Snead: Vust like the other slots, undo 

offCommands[i] = noCommand; starts of f with a NoCommand, so 
} Pressing undo before any other 
undoCommand = noCommand; button won't do anything at all. 


public void setCommand(int slot, Command onCommand, Command offCommand) { 
onCommands [slot] = onCommand; 
offCommands[slot] = offCommand; 


is pressed, we take 
public void onButtonWasPushed(int slot) When a button is " ) L 
onCommands [slot] .execute () the command and o pais 
undoCommand = onCommands ee it; then we save a re erence 
it in the undoCommand instance 
variable. We do this for both “on 
Pon ne Oe. Geese ioe bane ane cetee) a Commands and “off” commands. 


offCommands [slot] .execute() ; 
undoCommand = offCommands[slot]; 


n 


When the undo button is pressed, we 


public void undoButtonWasPushed () invoke the undol) method of the 
undoCommand. undo () ; command stored in undoCommand. 
} This reverses the operation of the 
last command executed. 
public String toString() { 
// toString code here... 
} 


Time to QA that Undo button! 


Okay, let’s rework the test harness a bit to test the undo button: 


public class RemoteLoader { 


{ 


public s 
Remo 


tatic void main(String[] args) 
teControlWithUndo remoteControl 


Light livingRoomLight 


LightOnCommand livingRoomLightOn 
new LightOnCommand(livingRoomLight) ; 
toffCommand livingRoomLightOff 


new LightOffCommand (livingRooml 


Ligh 


Light) 


remoteControl.setCommand(0, livingRooml 
remoteCon 
remoteCon 
System.ou 
remoteCon 
remoteCon 
remoteCon 
System.ou 


remoteCon 


trol.onButtonWasPushed (0) ; 
trol.offButtonWasPushed (0) 
t.println(remoteControl) ; 
trol.undoButtonWasPushed () 
trol.of fButtonWasPushed (0) 
trol.onButtonWasPushed (0) ; 
t.println(remoteControl) ; 
trol.undoButtonWasPushed () 


~ 


~ 


= 


~ 


And here’s the test results... 


File Edit Window Help UndoCommandsDefyEntropy 
% java RemoteLoader 

Light 

Light 


LightOn, 


new Light (“Living Room”) ; 


r 


1 


the command pattern 


new RemoteControlWithUndo (); 


f w dol) 
Create a Light, and our new un 
+f sbled Light On and OFF Commands 


ivingRoomLightOff) ; 


‘e Add the light Commands 
to the remote in slot O. 


a oe Turn the light on, then 


off and then undo. 


a turn the light off, back on and undo. 


Here's the Light commands. 


-command.u. 


- command. 


- command. 


-command.u. 


LightOffCommand 


Undo was pressed... the LightO££ Command 


undol) turns the light back on. 
 @_ Then we turn the light off then back on. 


Light 
on 


jee 


Um 
Now un 


do hele the 


LightO£fCommand, the last 
Command invoked. 


omm 


- command. 


headfirst. 
headfirst. 


ommand. 


ommand. u: 


-command.u. 


- command. 


Now undo holds the LightOnCommand, the last 
Command invoked. 
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we need to keep some state for undo 


Using state to implement Undo 


Okay, implementing undo on the Light was instructive but a little too easy. Typically, 
we need to manage a bit of state to implement undo. Let’s try something a little more 
interesting, like the CeilingFan from the vendor classes. The ceiling fan allows a 
number of speeds to be set along with an off method. 


high) 


low() 
off 
getSper 


Here’s the source code for the CeilingFan: 


class holds lotal 


public class CeilingFan { Ceilingran .\: 
public static final int HIGH = 3; Notice that be Lhe speed o& the ceilin), 
public static final int MEDIUM = 2; state represe” m9 


static final int LOW = 1; 
public static final int OFF 
String location; 

int speed; 


public 


public CeilingFan(String location) { 
this.location location; 


medium() 


CeilingFan 


ed() 


‘an- 
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speed = OFF; Hmm, so to properly 
} implement undo, I'd have 
to take the previous speed of 
public void high() { the ceiling fan into account... 
speed = HIGH; 
// code to set fan to high 


} 


public void 
speed = 
// code 
} 


public void 
speed = 
// code 
} 


public void 
speed = 
// code 
} 


public int getSpeed() { 
return speed; 


} 
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medium() { 
MEDIUM; 
to set fan to medium 


These methods set the 


lew! 4 speed of the ceiling fan. 


LOW; 
to set fan to low 


off() { | 
OFF; / 
to turn fan off 


+ 
ew 
tan get the ie 
a of the ceilin, fan 


anit gerSreed”: 
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Adding Undo to the ceiling fan commands 


Now let’s tackle adding undo to the various CeilingFan commands. ‘To 
do so, we need to track the last speed setting of the fan and, if the undo() 
method 1s called, restore the fan to its previous setting. Here’s the code for 
the CeilingFanHighCommand: 


public class CeilingFanHighCommand implements Command { weve added total state 
CeilingFan ceilingFan; kp keer brack of the 
int prevSpeed; Po ; of the fan. 


public CeilingFanHighCommand(CeilingFan ceilingFan) { 
this.ceilingFan = ceilingFan; 


} 


In execute, before we change 
public void execute() { as the speed of the fan, we 
prevSpeed = ceilingFan.getSpeed(); weed te Cie venand He 
ceilingFan.high(); 


} previous state, just in case we 
need to undo our attions 


jolbloninMoln Zeno mmbbelolon @ mnt 

if (prevSpeed == CeilingFan.HIGH) { 
ceilingFan.high (); 

} else if (prevSpeed == CeilingFan.MEDIUM) { 
ceilingFan.medium() ; To undo, we set the speed 

} else if (prevSpeed == CeilingFan.LOW) { s— of the fan back to its 
ceilingFan.low(); 

} else if (prevSpeed == CeilingFan.OFF) { 
ceilingFan.off(); 


Previous speed. 


} 


< WAIL 
POWER 


We've got three more ceiling fan commands to write: low, medium, and off. Can you see 
how these are implemented? 
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test the ceiling fan 


Get ready to test the ceiling fan 


Time to load up our remote control with the ceiling fan ee 


commands. We’re going to load slot zero’s on button with 
the medium setting for the fan and slot one with the high 
setting. Both corresponding off buttons will hold the ceiling 
fan off command. 


Here’s our test script: 


public class RemoteLoader { 


public static void main(String[] args) { 


RemoteControlWithUndo remoteControl = new RemoteControlWithUndo(); 


CeilingFan ceilingFan = new CeilingFan(“Living Room”); 


doin Nein ae Sei inal enedium = Deve we instantiate three 
_ new Cee Eng eee uncon (ceilingFan) ; L couwcnitle high, medium, and off. 
CeilingFanHighCommand ceilingFanHigh = 


new CeilingFanHighCommand(ceilingFan) ; 
CeilingFanOffCommand ceilingFanOff = 


Here we put medium in 


new CeilingFanOffCommand (ceilingFan) ; 4-—™ slot zero, and high in 


slot one. We also load 


remoteControl.setCommand(0, ceilingFanMedium, ceilingFanOff); up the off Commands. 


remoteControl.setCommand(1, ceilingFanHigh, ceilingFanOff) 


remoteControl.onButtonWasPushed(0); <———.\ First, 


remoteControl.offButtonWasPushed (0) ; < Then turn it off. 
System.out.printlin(remoteControl) ; 


, 


turn the fan on medium. 


remoteControl.undoButtonWasPushed() ; <____. Undo! [t should 90 back to medium... 


remoteControl.onButtonWasPushed (1) ; “—— _ Turn it on to high this time: 


System.out.println(remoteControl) ; And 
remoteControl.undoButtonWasPushed () ; &——— mm 


one more undo; 
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it should 90 back to medium. 
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Testing the ceiling fan... 


Okay, let’s fire up the remote, load it with commands, and push some buttons! 


File Edit Window Help UndoThis! 


2 


% java RemoteLoader 


s 
Living Room ceiling fan is on medium Turn the ceiling fan on Here are the Command 
Living Room ceiling fan is off a medium, then turn it off an the remote tontrol--- 


Remote Control a 
[slot 0] headfirst.command. .CeilingFanMediumCommand headfirst .command.umdo.CeilingFanOff- 
Command 
[slot 1] headfirst.command. .CeilingFanHighCommand headfirst .command.undo.CeilingFanOffCom- 
mand 
[slot headfirst .command. . NoCommand headfirst .command.undo.NoCommand 
store headfirst .command. . NoCommand headfirst .command.undo.NoCommand 
[slot headfirst.command. .NoCommand headfirst .command.undo.NoCommand and undo has the last 
[slot headfirst .command. - NoCommand headfirst .command.undo.NoCommand Command executed, the 
stor headfirst .command. . NoCommand headfirst .command.undo.NoCommand +): 
[undo] headfirst.command.undo.CeilingFanOffCommand ES Ceiling Fand £6 Command. 


Living Room ceiling fan is on medium @— Undo the last command, and it gces back to medium. 
Living Room ceiling fan is on high © Now, turn it high 
F on high. 


Remote Control 
[slot 0] headfirst.command. .CeilingFanMediumCommand headfirst .command.undo.CeilingFanOff- 
Command 
[slot 1] headfirst.command. .CeilingFanHighCommand headfirst .command.undo.CeilingFanOffCom- 
mand 
[slot 2] headfirst .command. . NoCommand headfirst .command.undo.NoCommand 
[slot 3] headfirst .command. . NoCommand headfirst .command.undo.NoCommand 
[slot 4] headfirst.command. . NoCommand headfirst .command.undo.NoCommand 
[slot 5] headfirst.command. . NoCommand headfirst .command.undo.NoCommand 
[slot 6] headfirst . .command.undo.NoCommand Now, high is the last 
[undo] headfirst.co 
command executed. 


Living Room ceiling fan is on medium One more undo, and the ceiling fan 


K_ goes back to medium speed. 
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macro commands 


Every remote needs a Party Mode! = 


on() 
off() 
setCd() 

setDvd() 


What’s the point of having a remote if you can’t stRed) a 
push one button and have the lights dimmed, the 7 nissan 
stereo and TV turned on and set to a DVD and the ong 


= ofl) 
hot tub fired up? crete 
jetsOn() 
jetsOff() 
setTemperature() 


dim() 


Hmm, our remote 
control would need a 
button for each device, I 
don't think we can do this. 


Hold on Sue, don't be 

so sure. I think we can 
do this without changing the 
remote at all 


Mary's idea is to make a new 
kind of Command that can 
execute other Commands... 

and more than one of them! 

Pretty good idea, huh? 


public class MacroCommand implements Command { 
Command[] commands; 


public MacroCommand(Command[] commands) { 
this.commands = commands; 


i. Take an array of 


Commands and store them in the MactroCommand. 


public void execute() { 


for (int i = 0; i < commands.length; i++) { 
commands [i] .execute () ; 
} RK When the macro gets executed by the remote, 


execute those Commands one at a time. 
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Using a macro command 


Let’s step through how we use a macro command: 


© First we create the set of commands we want to go into the macro: 


Create all the devices, a 
Light light = new Light (“Living Room”); “ light, tv, stereo, and hot tub. 


TV tv = new TV(“Living Room”) ; 
Stereo stereo = new Stereo(“Living Room”) ; 
Hottub hottub = new Hottub(); 


Now ereate all the On 


Y tommands to control them. 
LightOnCommand lightOn = new LightOnCommand (light) ; 
StereoOnCommand stereoOn = new StereoOnCommand (stereo) ; 


= 


rVOnCommand tvOn = new TVOnCommand (tv) ; 
HottubOnCommand hottubOn = new HottubOnCommand (hottub) ; 


G harpen your pencil We will also need commands for the off buttons, 
write the code to create those here: 
Create an array for On 

Next we create two arrays, one for the On commands and one for the Off com- and an array for Of 
mands, and load them with the corresponding commands: . (- Commands... 

Command[] partyOn = { lightOn, stereoOn, tvOn, hottubOn}; 

Command[] partyOff = { lightOff, stereoOff, tvOff, hottubOff}; 

MacroCommand partyOnMacro = new MacroCommand(partyOn) ; and create two 

MacroCommand partyOffMacro = new MacroCommand (partyOff) ; Corresponding macros 

to hold them. 


3) Then we assign MacroCommand to a button like we always do: "an Assign the macro 


command 
remoteControl.setCommand(0, partyOnMacro, partyOffMacro) ; nd to a button as 
we would any Command. 
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macro command exercise 


4.) Finally, we just need to push some buttons and see if this works. 


System.out.printlin(remoteControl) ; 


System.out.println(“--- Pushing Macro On---”); 
remoteControl.onButtonWasPushed (0) ; rm 

“ ; ” eres the output. 
System.out.printin(“--- Pushing Macro Off---”); 


remoteControl.offButtonWasPushed (0); 


File Edit Window Help You Can’tBeatABabka 


java RemoteLoader 

Remote Control 

headfirst .command. .MacroCommand headfirst .command.party.MacroCommand 
headfirst.command. . NoCommand headfirst.command.party.NoCommand 
headfirst.command. . NoCommand headfirst.command.party.NoCommand 
headfirst.command. . NoCommand headfirst.command.party.NoCommand 
headfirst.command. . NoCommand headfirst.command.party.NoCommand 
headfirst .command. . NoCommand headfirst .command.party.NoCommand 
headfirst.command. . NoCommand headfirst .command.party.NoCommand 

eadfirst .command.party.NoCommand 


Vn Here ave the two matro Commands. 


——~-eushingeMacco.On=—— 


Light is on 

Living Room stereo is on 

Living Room TV is on All the Commands in the macro 
Living Room TV channel is set for DVD are executed when we invoke 
Hottub is heating to a steaming 104 degrees the on matro... 

Hottub is bubbling! 


=—— 2GiSloalinte, Meeiae) (OR — 
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ILeMe als) OIE : 
Living Room stereo is off and when we invoke the off 


Living Room TV is off macro. Looks like it works. 
Hottub is cooling to 98 degrees 
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The only thing our MacroCommand is missing its undo functionality. When the 
undo button is pressed after a macro command, all the commands that were invoked 
in the macro must undo their previous actions. Here’s the code for MacroCommand; 
go ahead and implement the undo() method: 


public class MacroCommand implements Command { 


Command [ ] 


public MacroCommand (Command [] 
this.commands = 


commands; 


commands ) 
commands; 


public void execute() { 


for 


(int i = 0; 
commands [i] .execute() ; 


public void undo() { 


Q: Do | always need a receiver? 
Why can’t the command object 
implement the details of the 
execute() method? 


A: In general, we strive for “dumb” 
command objects that just invoke 
an action on a receiver; however, 
there are many examples of “smart” 
command objects that implement 
most, if not all, of the logic needed 
to carry out a request. Certainly 
you can do this; just keep in mind 
you'll no longer have the same level 
of decoupling between the invoker 
and receiver, nor will you be able to 
parameterize your commands with 
receivers. 


Dei Giestions 


+ Howcanl implement a history 
of undo operations? In other words, 
| want to be able to press the undo 
button multiple times. 


A: Great question! It’s pretty 
easy actually; instead of keeping just 


a reference to the last Command 
executed, you keep a stack of previous 
commands. Then, whenever undo is 
pressed, your invoker pops the first 
item off the stack and calls its undo() 
method. 


i < commands.length; 


itt) { 


Q: Could | have just implemented 
Party Mode as a Command by 
creating a PartyCommand and 
putting the calls to execute the other 
Commands in the PartyCommand’s 
execute() method? 


A: You could; however, you’d 
essentially be “hardcoding” the 
party mode into the PartyCommand. 
Why go to the trouble? With the 
MacroCommand, you can decide 
dynamically which Commands you 
want to go into the PartyCommand, 
so you have more flexibility using 
MacroCommands. In general, the 
MacroCommand is a more elegant 
solution and requires less new code. 
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queuing requests 


More uses of the Command Pattern: queving requests 


Commands give us a way to package a piece of 
computation (a receiver and a set of actions) and pass it 
around as a first-class object. Now, the computation itself 
may be invoked long after some client application creates 
the command object. In fact, it may even be invoked by a Commands 
different thread. We can take this scenario and apply it to 
many useful applications such as schedulers, thread pools 


: . : enting the buted? 
and job queues, to name a few. Objects implem ae (~..) $ 
. . command interface riod G5 
Imagine a job queue: you add commands to the queue dded to the queue. * § ror 
; a S 
on one end, and on the other end sit a group of threads. ‘ €--) Tone 


Threads run the following script: they remove a command 


a . ( RayTra® 
from the queue, call its execute() method, wait for the call ©), Or 
. . . . v ile 
to finish, then discard the command object and retrieve a 7 @r* a 
new one. Peatcone ayo” 
Ww 


This gives us an effective way 
to limit Computation toa 
fixed number of threads. 


Threads remove Commands 


from the queue one by one O; 
and call their exeeute( ~ ils 
method. Once complete, 

they go back for a new 


command object. Thread 
Thread 


Threads computing 
jobs 


Note that the job queue classes are totally decoupled from the ob- 
jects that are doing the computation. One minute a thread may be 
computing a financial computation, and the next it may be retrieving 
something from the network. The job queue objects don’t care; they 
just retrieve commands and call execute(). Likewise, as long as you How might a web server make 
put objects into the queue that implement the Command Pattern, use of such a queue? What other 
your execute() method will be invoked when a thread is available. applications can you think of? 
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More uses of the Command Pattern: logging requests 


The semantics of some applications require that we log all actions and be able to 
recover after a crash by reinvoking those actions. The Command Pattern can support 
these semantics with the addition of two methods: store() and load(). In Java we could 
use object serialization to implement these methods, but the normal caveats for using 
serialization for persistence apply. 


Ssinterfacess 


. : : Comm, 
How does this work? As we execute commands, we store a history of them on disk. Pee 
When a crash occurs, we reload the command objects and invoke their execute() undo() 


methods in batch and in order. store() 
load() 


— 


Now, this kind of logging wouldn’t make sense for a remote control; however, there 
are many applications that invoke actions on large data structures that can’t be quickly 


saved each time a change is made. By using logging, we can save all the operations 
since the last check point, and if there 1s a system failure, apply those operations to our 
checkpoint. Take, for example, a spreadsheet application: we might want to implement 
our failure recovery by logging the actions on the spreadsheet rather than writing a copy 
of the spreadsheet to disk every time a change occurs. In more advanced applications, We add two methods 
these techniques can be extended to apply to sets of operations in a transactional 


for logging, 


manner so that all of the operations complete, or none of them do. 


0, ser 
oe 


*" 2. execute() 


execute Q 
store() 


After a system failure, 
the objects are 


LhvoKer rman 
Avo = Crash! veloaded and executed 
By in the corrett order. 
oad () 
Ope KJ 
™mand Restore 


hs each command 
is executed, it is Cee 


stored on disk. load () 
6 CS v 
yo" : 
= x mando * Q Peo, 
load i 


execute ‘a 
store () 


doad() e 
“Amand 


Lhvower 
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Tools for your Design Toolbox 


Your toolbox is starting to get heavy! In this chapter 
we’ve added a pattern that allows us to encapsulate 


methods into Command objects: store them, pass them 


around, and invoke them when you need them. 


OO Principles 
ulate what varies: 
a position over anerit ance: 


Favor bor 
not 


Program to nberkacess 
immplementauier® 
courled designs 


loosely anteratt- 


dyive for 
oe objets hat 
en xO" 
< should be oF 
sects but closed Lor 
podixicacior 
" abstractions: Do no 
n tonerete classes: 


When you need to yee ie an 
object making requests i. 
the objects that know ate 
perform the requests) use 


\ Command Pattern. 


Derend © 
derend © 


S ¢ " 4 > \ 
ev \D Ac! AA = Ne j= 
mv aa ee G ae ft 
1) 4 Sin * culates 3 vewwe 
“\ 4 ai \ one Command - EntaP Vetting Yo“ 
WANES viet: thereby eet”. Rs ent 
£ “Sin of gs an ob)er™ vents with dirrer 
_ a gramevert : \ an 
s eayests> queue OF 
a 
=" suRre 
= | 
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BULLET as 


The Command Pattern 
decouples an object making 
a request from the one that 
knows how to perform it. 


A Command object is at the 

center of this decoupling and 
encapsulates a receiver with 
an action (or set of actions) . 


An invoker makes a request of 
a Command object by calling 
its execute() method, which 
invokes those actions on the 
receiver. 


Invokers can be parameterized 
with Commands, even 
dynamically at runtime. 


Commands may support undo 
by implementing an undo 
method that restores the object 
to its previous state before 

the execute() method was last 
called. 


Macro Commands are a simple 
extension of Command that 
allow multiple commands to 

be invoked. Likewise, Macro 
Commands can easily support 
undo(). 


In practice, it is not uncommon 
for “smart” Command objects 
to implement the request 
themselves rather than 
delegating to a receiver. 


Commands may also be used 
to implement logging and 
transactional systems. 


the command pattern 


Time to take a breather and let it all sink in. 


It’s another crossword; all of the solution words are from 
this chapter. 


PL 
rt 
re 


aia 


Across Down 

3. The Waitress was one 1. Role of customer in the command pattern 
4.Acommand____asetof actions anda 2. Our first command object controlled this 
receiver 5. Invoker and receiver are 

7. Dr. Seuss diner food 6. Company that got us word of mouth business 
8. Our favorite city 10. All commands provide this 

9. Act as the receivers in the remote control 11. The cook and this person were definitely 

13. Object that knows the actions and the decoupled 

receiver 12. Carries out a request 


14. Another thing Command can do 16. Waitress didn't do this 
15. Object that knows how to get things done 
17. Acommand encapsulates this 
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exercise solutions 


Exereise 
solutions 


a your pencil 


senra'wa Bw 
WuUus BOE: WUAT? 


Match the diner objects and methods with the corresponding names from the 
Command Pattern 


Diner Command Pattern 


Waitress Command 


Short Order Coo! execute() 


orderUpO Client 


invoker 


Order 


Customer Receiver 


takeOrder(Q) setCommand() 


public class GarageDoorOpenCommand implements Command { 
GarageDoor garageDoor; 


public GarageDoorOpenCommand(GarageDoor garageDoor) { 
this.garageDoor = garageDoor; 


} 


public void execute ( 
garageDoor.up(); 


Garage Door is Open 


% 
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Write the undo() method for MacroCommand 


eRciSe 


public class MacroCommand implements Command { 
Command[] commands; 
public MacroCommand(Command[] commands) { 
this.commands = commands; 


} 


public void execute() { 
for (int i = 0; i < commands.length; i++) { 
commands [i] .execute(); 
} 
} 


public void undo() { 
for (int i = commands.length - 1; i > = 0; i--) { 
commands [i] .undo(); 


Write the code to create those here: 


G@ harpen your pencil We will also need commands for the off button. 
aN 


LightOffCommand lightOff = new LightOffCommand (light) ; 
StereoOffCommand stereoOff = new StereoOffCommand (stereo) ; 
TvOffCommand tvOff = new TVOffCommand (tv) ; 
HottuboffCommand hottubOff = new HottubOffCommand (hottub) ; 


ft |n|vlolk}e la 
le SRP EMESSEANEH AA 
A T 


A 
gett eeabe 
H 
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7 the Adapter and Facade Patterns 


+ Being Adap tive’, 


Do you think the readers are 
really getting the impression we're 
watching a horse race rather than 
sitting in a photo studio? 


That's the 
beauty of our profession, 

we can make things look 

like something they're not! 


You 

mean it's not 
supposed to bea 
football match? 


Wrapped in 
this coat, I'ma 
different man! 


In this chapter we’re going to attempt such impossible feats as 
putting a square peg in a round hole. Sound impossible? Not when we have 
Design Patterns. Remember the Decorator Pattern? We wrapped objects to give them new 
responsibilities. Now we’re going to wrap some objects with a different purpose: to make their 
interfaces look like something they’re not. Why would we do that? So we can adapt a design 
expecting one interface to a class that implements a different interface. That’s not all; while 
we're at it, we’re going to look at another pattern that wraps objects to simplify their interface. 
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adapters everywhere 


Adapters all around us 


You’ll have no trouble understanding what an OO adapter is 
because the real world is full of them. How’s this for an example: 
Have you ever needed to use a US-made laptop in a European 
country? Then you’ve probably needed an AC power adapter... 


European Wall Outlet 


AC Power Adapter 
Standard AC Plug 


a) <S_ 


The US laptop expects 
another interface. 


ses 
- wall outlet ae 
The Eurore : for oetting ¥ 
Af 


one wt Lae Ne A 


The adapter converts one 
interface into another. 


You know what the adapter does: it sits in between the plug of your laptop and the 


European AC outlet; its job is to adapt the European outlet so that you can plug your set 
laptop into it and receive power. Or look at it this way: the adapter changes the interface eae ar? 
of the outlet into one that your laptop expects. ers bP 


gd2X 


Some AC adapters are simple — they only change the shape of the outlet so that it matches 
your plug, and they pass the AC current straight through — but other adapters are more 
complex internally and may need to step the power up or down to match your devices’ 
needs. 


Okay, that’s the real world, what about object oriented adapters? Well, our OO adapters 
play the same role as their real world counterparts: they take an interface and adapt it to 
one that a client is expecting. 
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the adapter pattern 


Object oriented adapters 


Say you’ve got an existing software system that you need to work a new vendor class library 
into, but the new vendor designed their interfaces differently than the last vendor: 


es endor 
Existing : ” 
System ¢ a 
Th atten 
a esnt matth the one wl ve we 
eur anterkate Co) ee 


t. This ' isnt goin 


your code agains 


Okay, you don’t want to solve the problem by changing your existing code (and you can’t 
change the vendor’s code). So what do you do? Well, you can write a class that adapts the 
new vendor interface into the one you’re expecting. 


Your Adapter Vendor 
Existing Class 
System 
: on w £ c 
The adapter implements the 4 4 talks to the mane terrace 
interface Your Classes expect. service You" requests 


The adapter acts as the middleman by receiving requests from the client and converting 
them into requests that make sense on the vendor classes. 


thin 
Your Adapter Vendor eae net £ require you 
ae pas wee ANY additional oe 
System be oe the new [ ae 
w makin 
aan w about Ler class: 


No ode les oe ae No dbde changes. 
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turkey adapter 


If it walks like a duck and quacks like a duck, 
then it must might be a-duek turkey wrapped 
with a duck adapter... 


It’s time to see an adapter in action. Remember our 
ducks from Chapter 1? Let’s review a slightly simplified 
version of the Duck interfaces and classes: 


vo 


e av ound, our 


public interface Duck { This ‘ive \ ment a Duck 
public void quack(); ducks wk ch allows 
public void fly(); inberkate a fly: 

Ducks te avack 3m 


Here’s a subclass of Duck, the MallardDuck. 


public class MallardDuck implements Duck { 
public void quack() { duck 
. . : e au 
System. out.printin (“Quack”) ; : Jementarions th 
Simple ww? it is doin, 
ae st prints out, what | 
y 
public void fly() { — 
System.out.println(“I’m flying”) ; 
} 


Now it’s time to meet the newest fowl on the block: 


Turkeys dont quack, they gobble: 
ue 


public interface Turkey { 
public void gobble(); 


public void fly(); 
} oe Turkeys can fy, although they 
tan only fly short distances. 
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c (4 tation 
Here's 3 eonerete implemen 


public class WildTurkey implements Turkey { wb aust 
. tk, it jw 
public void gobble() { of Turkey; like : : J 
System.out.printlin(“Gobble gobble”); prints out its aLions- 


} 


public void fly() { 
System.out.printlin(“I’m flying a short distance”) ; 


} 


Now, let’s say you’re short on Duck objects and you'd like to 
use some Turkey objects in their place. Obviously we can’t 
use the turkeys outright because they have a different interface. 


So, let’s write an Adapter: 


XP Code Up Close 


public class TurkeyAdapter implements Duck { 
Turkey turkey; 


First, you need to implement the interface 
of the type you're adapting to. This is the 
interface your client expects to see. 


Next, we need to get a reference to the 


public TurkeyAdapter (Turkey turkey) { a object that we are adapting; here we do 
this.turkey = turkey; that through the Constructor. 


} 


public void quack() { Now we need to implement all the methods in 
turkey.gobble(); JS the interface; the quack() translation between 
} classes is easy: just ¢all the gobble() method. 


public void fly() { 
for(int i=0O; i < 5; itt) { 

a a a: ’ Even though both interfaces have a fly() 

: method, Turkeys fly in short spurts — they 

can't do long—distance flying like ducks. To 
map between a Duck's AyO method and a 

Turkey's, we need to ¢all the Turkey's fly() 

method five times to make up for it. 
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Test drive the adapter 


Now we just need some code to test drive our adapter: 


public class DuckTestDrive { 
public static void main(String[] args) { a 
MallardDuck duck = new MallardDuck(); 


WildTurkey turkey = new WildTurkey(); 


Duck turkeyAdapter = new TurkeyAdapter (turkey) ; 


\. 
Lets peace 3 De 
and 3 Turkey 


And then wrap the turkey 
Lf ina TurkeyAdapter, whith 


System.out.printlin(“The Turkey says...”); 
turkey.gobble(); 
turkey.fly(); 


System.out.println(“\nThe Duck says...”); 
testDuck (duck) ; 


testDuck (turkeyAdapter) ; 
} 


static void testDuck(Duck duck) { 


makes it look like a Duck. 


S—__ Then, let's test the Turkey: make 
it gobble, make it fly. 


Now let’s test the duck 
by calling the testDuek() 


System.out.println(“\nThe TurkeyAdapter says...”); method, which expects a 
) 


Duek object. 


< F urk we tr 
2 a ae si S our testDuek() method; it ee dk . i 
; ‘ Jets a duck and calle dt. | - 
} nd éalls its 
and Ay) methods. rts quack() 
Test run ( W 


240 


Sjava DuckTestDrive 


The Turkey says... 
Gobble gobble 
I’m flying a short distance 


The Duck says... 
Quack 
I’m flying 


The TurkeyAdapter says... 
(efo) 0) of KWo fo) 0) oN K-) 

I’m flying a short distance 
I’m flying a short distance 
I’m flying a short distance 
I’m flying a short distance 
I’m flying a short distance 


a 
a 
re 
ro 


Chapter 7 


The Turkey gobbles and 
flies a short distance. 


The Duck quacks and flies 
x just like you'd expect: 


And the adapter gobbles when 


ack) is called and flies a few times 
oa a AyO is talled. The test DuckO 


method never knows it has a turkey 
disguised as a duck! 


the adapter pattern 


The Adapter Pattern explained 


Now that we have an idea of what an Adapter is, let’s step back 
and look at all the pieces again. 


Adaptee 
bite request 
The Client is implemented 
against the target interface. 
Adapter 
inate 
et antertac? erface 
1d) 
= The Adapter implements the Turkey was the 
target interface and holds an adaptee interface 
instance of the Adaptee. a 
ence 
toes at wher one 7 Dutk 


khe 12 
Here's how the Client uses the Adapter 


e The client makes a request to the 
adapter by calling a method on it using 
the target interface. Note that the sak aod 
Low led - nether 

© The adapter translates the request into - the other: 

One or more calls on the adaptee using 
the adaptee interface. 


@ The client receives the results of the 


call and never knows there is an adapter 
doing the translation. 
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G harpen our pencil 
“ 


Let’s say we also need an Adapter that converts a Duck to a Turkey. 
Let’s call it DuckAdapter. Write that class: 


How did you handle the fly method (after all we know ducks fly longer than turkeys)? Check the answers at 
the end of the chapter for our solution. Did you think of a better way? 


Q: How much “adapting” does 

an adapter need to do? It seems like 

if | need to implement a large target 
interface, | could have a LOT of work on 
my hands. 


A: You certainly could. The job 

of implementing an adapter really is 
proportional to the size of the interface you 
need to support as your target interface. 
Think about your options, however. You 
could rework all your client-side calls to 
the interface, which would result in a lot 

of investigative work and code changes. 
Or, you can cleanly provide one class that 
encapsulates all the changes in one class. 


242 


there are no 


Dumb Questions 


* Does an adapter always wrap one 
and only one class? 


A: The Adapter Pattern’s role is to 
convert one interface into another. While 
most examples of the adapter pattern show 
an adapter wrapping one adaptee, we both 
know the world is often a bit more messy. 
So, you may well have situations where an 
adapter holds two or more adaptees that are 
needed to implement the target interface. 


This relates to another pattern called the 
Facade Pattern; people often confuse the 
two. Remind us to revisit this point when we 
talk about facades later in this chapter. 


+ What if | have old and new parts 
of my system, the old parts expect the 
old vendor interface, but we’ve already 
written the new parts to use the new 
vendor interface? It is going to get 
confusing using an adapter here and the 
unwrapped interface there. Wouldn’t | be 
better off just writing my older code and 
forgetting the adapter? 


A: Not necessarily. One thing you 
can do is create a Two Way Adapter that 


supports both interfaces. To create a Two 
Way Adapter, just implement both interfaces 
involved, so the adapter can act as an old 
interface or a new interface. 
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Adapter Pattern defined 


Enough ducks, turkeys and AC power adapters; let’s get real and look at the official 
definition of the Adapter Pattern: 


The Adapter Pattern converts the interface of a class 
into another interface the clients expect. Adapter lets 


classes work together that couldn’t otherwise because of 
incompatible interfaces. 


Now, we know this pattern allows us to use a client with an incompatible interface by 
creating an Adapter that does the conversion. This acts to decouple the client from 
the implemented interface, and if we expect the interface to change over time, the 
adapter encapsulates that change so that the client doesn’t have to be modified each 
time it needs to operate against a different interface. 


We've taken a look at the runtime behavior of the pattern; let’s take a look at its class 
diagram as well: 


Client <<interface>> ~~ The Adapter implements 
Target the Target interface. 
request() 
The client sees only the J 


Target interface. 
Adapter Adaptee 
request() specificRequest() 


All requests get 
Adapter 1S Composed cae delegated to the 
with the Adaptee. Adaptee- 


The Adapter Pattern is full of good OO design principles: check out the use of object 
composition to wrap the adaptee with an altered interface. This approach has the 
added advantage that we can use an adapter with any subclass of the adaptee. 


Also check out how the pattern binds the client to an interface, not an 
implementation; we could use several adapters, each converting a different backend 
set of classes. Or, we could add new implementations after the fact, as long as they 
adhere to the ‘Target interface. 
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Object and class adapters 


Now despite having defined the pattern, we haven’t told you the whole story yet. 
There are actually two kinds of adapters: object adapters and class adapters. This 
chapter has covered object adapters and the class diagram on the previous page is a 
diagram of an object adapter. 


So what’s a class adapter and why haven’t we told you about it? Because you need 
multiple inheritance to implement it, which isn’t possible in Java. But, that doesn’t 
mean you might not encounter a need for class adapters down the road when using 
your favorite multiple inheritance language! Let’s look at the class diagram for 
multiple inheritance. 


Client Target Adaptee 


request() specificRequest() 


Adapter 
request() 


Instead of using composition 
to adapt the Adaptee, the 
Adapter now subclasses the 
Adaptee and the Target 
classes. 


Look familiar? That’s right — the only difference is that with class adapter we 
subclass the Target and the Adaptee, while with object adapter we use composition 
to pass requests to an Adaptee. 


‘ BRAIN 
POWER 


Object adapters and class adapters use two different means of 
adapting the adaptee (composition versus inheritance). How do these 


implementation differences affect the flexibility of the adapter? 
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Duck Magnets 


Your job is to take the duck and turkey magnets and 
drag them over the part of the diagram that describes 
the role played by that bird, in our earlier example. (‘Try 
not to flip back through the pages.) Then add your own 
annotations to describe how it works. 


Class Adapter 


Client > Target Adaptee 
request() specificRequest() 
Adapter 
request) 
Object Adapter 
Client a <<interface>> 
Target 
request() 
aR 
Adapter —__ > Adaptee 
request() specificRequest() 
Dra 
; cae onto the ¢lass diagram 
? 
— which part of the diagram 
Presents the Duek and which 


represents the Turkey. 
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exercise answers 

Note: the ¢lass adapter uses 
multiple inheritance, So You 
Can't do it in Java... : 


Turkey Class 


Duek elass 


Class Adapter 


Client Adaptee 
request() specificRequest() rl aa 
Client thi ) ; tlass does 
ly se re Target 8 The Turkey methods 38 
9 toa Duck. x class: TS have the darter ta 
as + the client Duck, ow th ny a tall 
is Wha sthods OF Adapter take Du me pee invoke 
apvokes m request() and uien ge Turkey: 
The Adapter | edrods on te 
‘e de Pter ets the Turkey respond to 
a. ona Duek, by extendin BOTH 
elasses (Duck and Turkey), 9 
Duck interface. 
Object Adapter 
; ; The Turke , 
Client <<interface ; Y tlass do 
ien ————> Target eile as the Duk pines 
oa thinks he’s f) = oe eee have quack() methods a 
king toa : ates 
age st as with Class ceria 
lu : 
khe Target i‘ ant khe lent Turkey 
\ass- T ° . : object. 
Cees mw tnods i Adapter Adaptee 9 
request() ad specificRequest() 
Turkey 
The Adapter ; he Adapter the 7 
deelace Wig aera pe Dick = Trans : a get tals that a 
method call it ee (ndartee the Duck inter 
it turns around and ent makes on 


delegates the calls to 4 Turkey. 
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Fireside Chats 


the adapter pattern 


Tonight’s talk: The Object Adapter and Class Adapter 


Cj meet face to face. 
\ 
_» 
OW 
Object Adapter Class Adapter 


Because I use composition I’ve got a leg up. I can 
not only adapt an adaptee class, but any of its 
subclasses. 


In my part of the world, we like to use 
composition over inheritance; you may be 
saving a few lines of code, but all I’m doing 1s 
writing a little code to delegate to the adaptee. 
We like to keep things flexible. 


You're worried about one little object? You 
might be able to quickly override a method, 
but any behavior I add to my adapter code 
works with my adaptee class and all its 
subclasses. 


Hey, come on, cut me a break, I just need to 
compose with the subclass to make that work. 


You wanna see messy? Look in the mirror! 


That’s true, I do have trouble with that because 
I am committed to one specific adaptee class, 
but I have a huge advantage because I don’t 
have to retmplement my entire adaptee. I can 
also override the behavior of my adaptee if I 
need to because I’m just subclassing. 


Flexible maybe, efficient? No. Using a class 
adapter there is just one of me, not an adapter 
and an adaptee. 


Yeah, but what if a subclass of adaptee adds 
some new behavior. ‘Then what? 


Sounds messy... 
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Real world adapters 


Let’s take a look at the use of a simple Adapter in the real world 
(something more serious than Ducks at least)... 


Old world Enumerators 


. on 
If you’ve been around Java for a while En erat 
you probably remember that the early Cc ' if there ave any more 
collections types (Vector, Stack, Hashtable, <<interface>> Tells you § llethion 
‘ Enumeration elements in the colle 
and a few others) implement a method / 
P hasMoreElements() 
elements(), which returns an Enumeration. nextElement() 
The Enumeration interface allows you to >, 
step through the elements of a collection Gives you the next element 
without knowing the specifics of how they in the collection. 


are managed in the collection. 


Analogous to hasMoreElements() 
in the Enumeration inter ate 
This method just tells you if 


When Sun released their more recent uve lerked 2 —— 
<<interface> the collection. 


Collections classes they began using an Iterator 

Iterator interface that, like Enumeration, hasNext() 

allows you to iterate through a set of items jaca ' <—__ Gives ha the next 

in a collection, but also adds the ability to clement in the collection. 


remove items. 


New world Iterators 


Removes an item from 
the collection. 


And today... 


We are often faced with legacy code that exposes the 
Enumerator interface, yet we'd like for our new code to use 
only Iterators. It looks like we need to build an adapter. 
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Adapting an Enumeration to an Iterator 


First we’ll look at the two interfaces to figure out how the methods map from 
one to the other. In other words, we’ll figure out what to call on the adaptee 


when the client invokes a method on the target. 
These two methods look easy, 
they map straight to hasNext() 


Target interface and next() in [terator. 
<<interface>> <<interface>> 
Iterator Enumeration 
hasNext() hasMoreElements() 
next() a) nextElement() 
remove() 


t. Adaptee interface 


But what about this method 
vemove() in [terator? There’s 
nothing like that in Enumeration. 


Designing the Adapter 


Here’s what the classes should look like: we need an adapter that implements 
the ‘Target interface and that is composed with an adaptee. he hasNext() and 
next() methods are going to be straightforward to map from target to adaptee: 
we just pass them right through. But what do you do about remove()? ‘Think 
about it for a moment (and we’ll deal with it on the next page). For now, here’s 
the class diagram: 


Your new Code still gets nce We're making the Enumerations 

to use [terators, even —Y | Merafor in Your old code look like 

if there’s really an hasNext() Iterators for your new code. 

Enumeration underneath. next() we 

remove() implementing 
the Enumeration 
—_ interkace is the 

adaptee- 


<<interface>> 


Enumerationlterator —> Enumerationlterator Enumeration 


is the adapter. 


hasNext() hasMoreElements() 
next() nextElement() 
remove() 
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Dealing with the remove() method 


Well, we know Enumeration just doesn’t support remove. It’s a “read only” interface. 
There’s no way to implement a fully functioning remove() method on the adapter. ‘The 
best we can do is throw a runtime exception. Luckily, the designers of the Iterator 
interface foresaw this need and defined the remove() method so that it supports an 
UnsupportedOperationException. 


This is a case where the adapter isn’t perfect; clients will have to watch out for potential 
exceptions, but as long as the client is careful and the adapter 1s well documented this is 
a perfectly reasonable solution. 


Writing the Enumerationlterator adapter 


Here’s simple but effective code for all those legacy classes still producing Enumerations: 


a, Cinte we've adapting Enumeration 
to Iterator, our Adapter 


public class EnumerationIterator implements Iterator implements the Iterator interface... 
{ it has to look like an Iterator. 
Enumeration enum; 
The Enumeration we're adapting, 
public EnumerationIterator (Enumeration Siti We're using, Composition so we stash 
this.enum = enum; it in an instance variable. 
The [terator’s hasNext() method 
public boolean hasNext() { = is delegated to the Enumeration’s 
return enum.hasMoreElements () ; hasMoreElements() method... 
} .. and the [terator’s next) method 
public Object next() { > aa is delegated to the Enumerations’s 
return enum.nextElement (); nextElement() method. 
} 
public void remove() { =—$_ Unfortunately, we cant support 
throw new UnsupportedOperationException (); Iterator’s removel) method, so 
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we have to punt (in other words, 


we give up!). Here we just throw 
an exception. 
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While Java has gone in the direction of the Iterator, there is nevertheless a lot of 
legacy client code that depends on the Enumeration interface, so an Adapter 


that converts an Iterator to an Enumeration is also quite useful. 


Write an Adapter that adapts an Iterator to an Enumeration. You can test your 
code by adapting an ArrayList. The ArrayList class supports the Iterator interface 
but doesn’t support Enumerations (well, not yet anyway). 


oe RAW 
Some AC adapters do more than just change the interface — they add other features like surge 
protection, indicator lights and other bells and whistles. 


If you were going to implement these kinds of features, what pattern would you use? 


fireside chats: decorator and adapter 


ee Chats 
A 
ae 


Vas 


Decorator 


[I’m important. My job is all about responsibility — 
you know that when a Decorator 1s involved there’s 
going to be some new responsibilities or behaviors 
added to your design. 


That may be true, but don’t think we don’t 
work hard. When we have to decorate a big 
interface, whoa, that can take a lot of code. 


Cute. Don’t think we get all the glory; sometimes 
I’m just one decorator that is beng wrapped by 
who knows how many other decorators. When a 
method call gets delegated to you, you have no 
idea how many other decorators have already dealt 
with it and you don’t know that you'll ever get 
noticed for your efforts servicing the request. 
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Tonight’s talk: The Decorator Pattern and the Adapter 
Pattern discuss their differences. 


Adapter 


You guys want all the glory while us adapters 
are down in the trenches doing the dirty work: 
converting interfaces. Our jobs may not be 
glamorous, but our clients sure do appreciate 
us making their lives simpler. 


‘Try being an adapter when you’ve got to bring 
several classes together to provide the interface 
your client is expecting. Now that’s tough. But 
we have a saying: “an uncoupled client is a 
happy client.” 


Hey, if adapters are doing their job, our clients 
never even know we’re there. It can be a thank- 
less job. 


Decorator 


Well us decorators do that as well, only we allow 
new behavior to be added to classes without altering 
existing code. I still say that adapters are just fancy 


decorators — I mean, just like us, you wrap an object. 


Uh, no. Our job in life is to extend the 
behaviors or responsibilities of the objects we 
wrap, we aren't a semple pass through. 


Maybe we should agree to disagree. We seem 
to look somewhat similar on paper, but clearly 
we are miles apart 1n our intent. 
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Adapter 


But, the great thing about us adapters 1s that we 
allow clients to make use of new libraries and 
subsets without changing any code, they just rely 
on us to do the conversion for them. Hey, it’s a 
niche, but we’re good at it. 


No, no, no, not at all. We always convert the 
interface of what we wrap, you never do. [’d 
say a decorator 1s like an adapter; it is just that 
you don’t change the interface! 


Hey, who are you calling a simple pass 
through? Come on down and we'll see how 
long you last converting a few interfaces! 


Oh yeah, I’m with you there. 


who does 


And now for something different... 


There’s another pattern in this chapter. 


You’ve seen how the Adapter Pattern converts the interface of a class into 
one that a client is expecting. You also know we achieve this in Java by 
wrapping the object that has an incompatible interface with an object that 
implements the correct one. 


We're going to look at a pattern now that alters an interface, but for a 
different reason: to simplify the interface. It’s aptly named the Facade 
Pattern because this pattern hides all the complexity of one or more 
classes behind a clean, well-lit facade. 


+o 


+ 
WUuUG BOES WHAT? 


Match each pattern with its intent: 


Pattern Intent 


Converts one interface to 
Decorator another 


Adapter Doesn'talterthe interface, but 
adds responsibility 


Facade 
Makes an interface simpler 
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Home Sweet Home Theater 


Before we dive into the details of the Facade Pattern, let’s take a look 
at a growing national obsession: building your own home theater. 


You’ve done your research and you've assembled a killer system 
complete with a DVD player, a projection video system, an 
automated screen, surround sound and even a popcorn popper. 


Check out all the components you’ve put together: 


rf Amplifier 
tuner 
dvdPlayer 
[| cdPlayer 
on() 
off) 
Tuner setCd{() 
amplifier setDvd() DvdPlayer 
setStereoSound() amplifier 
a setSurroundSoud() = That’s a lot of 
n 
setTuner() 
sala) setVolume() oft) classes, a lot 
setFm() eject() £ . tj 
setFrequency/) pause() ° interac: tons, 
play() and a bia set 
play() . 
setSurroundAudio() of inter aces to 
3 CdPlayer setTwoChannelAudio() | earn and use 
amplifier stop() 
Screen on() 
off) 
eject() 
pause() 
play() 
play() 5 
stop() Projector 
dvdPlayer 
PopcornPopper on() 
off() 
on() tvMode() 
off) TheaterLights wideScreenMode() 
pop() 
on() 
off) 
dim() 


You've spent weeks running wire, mounting the projector, making all 
the connections and fine tuning. Now it’s time to put it all in motion 
and enjoy a movie... 
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tasks to watch a movie 


Watching a movie (the hard way) 


Pick out a DVD, relax, and get ready for movie magic. Oh, 
there’s just one thing - to watch the movie, you need to 
perform a few tasks: 


@ Turn on the popcorn popper 

© Start the popper popping 

© Dim the lights 

© Put the screen down 

© Tourn the projector on 

© Set the projector input to DVD 

@ Put the projector on wide-screen mode 
© Turn the sound amplifier on 

© Set the amplifier to DVD input 

© Set the amplifier to surround sound 

® Set the amplifier volume to medium (9) 
® Turn the DVD Player on 

® Start the DVD Player playing 


I'm already exhausted 
and all I've done is turn 
everything on! 


the adapter pattern 


Let’s check out those same tasks in terms of the classes and the 
method calls needed to perform them: 


Turn on the popcorn popper and start 


a popping. 
popper.on(); 


popper.pop(); Dim the lights to 1O%... 


lights.dim(10); a 
screen.down (); aoe ee Put the sereen down... 


projector.on(); 

projector.setInput (dvd) ; Taxi ob the projector and put it in 
jector.widesS Mod 1 

projector.wideScreenMode () wide streen mode for the movie 


Six different classes 
involved: 


I\S~ 


amp.on(); 


amp.setDvd (dvd) ; : 
amp.setSurroundSound () ; a Turn on the amp, set it to anne 
amp.setVolume (5) ; it in surround sound mode and se 
volume to 9.-- 
dvd.on(); 
dvd.play (movie) ; 
Turn on the DvD player. ae 


FINALLY, play the movie 


But there’s more... 

When the movie is over, how do you turn everything off? 
Wouldn’t you have to do all of this over again, in reverse? 

=" Wouldn’t it be as complex to listen to a CD or the radio? 

If you decide to upgrade your system, you’re probably going 


to have to learn a slightly different procedure. 


So what to do? The complexity of using your home theater is becoming apparent! 


Let’s see how the Facade Pattern can get us out of this mess so we can enjoy the movie... 
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lights camera facade 


Lights, Camera, Facade! 


A Facade is just what you need: with the Facade Pattern you can take a complex 


subsystem and make it easier to use by implementing a Facade class that 


provides one, more reasonable interface. Don’t worry; if you need the power 


of the complex subsystem, it’s still there for you to use, but if all you need is a 
straightforward interface, the Facade is there for you. 


Let’s take a look at how the Facade operates: 


The subsystem 


Okay, time to create a 
Facade for the home 
theater system. To do 
this we create a new class 
HomeTheaterFacade, 
which exposes a few 
simple methods such as 
watchMovie(). 


the ? 


Facade 1s simplifying) 
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The Facade 


HomeTheaterFacade 


watchMovie() 
endMovie() 
listenToCd() 
endCd() 
listenToRadio() 
endRadio() 


7 \\ 


upl) 
down) 


Va 


Tuner 
amplifier 
‘on() 
off() 
setAm() 
‘setFm() 
‘setFrequency() 


Screen 


PopcornPopper 
‘on() 
off() 
pop() 


tuner 
dvdPlayer 
7 cdPlayer 

oni) 
off() 
setCdl) 
setDvdl) 
setStereoSound() 
setSurroundSoud() 
setTuner() 
setVolume() 


amplifier 
oni) 
off) 
eject() 


pause() 
play() 
play() 
stop() 


TheaterLights 


\ 


CdPlayer 


amplifier 


oni) 

oft) 

elect) 

pausel) 

play() 

play() 
setSurroundAudio() 
setTwoChannelAudio() 
stop() 


Projector 


dvdPlayer 


oni) 

ofl) 

tvMode() 
wideScreenMode() 


2) The Facade class treats 
the home theater 


components as a 
subsystem, and calls 
on the subsystem 

to implement its 
watchMovie() method. 


> DvdPlayer 


Chapter 7 


the adapter pattern 


hMovie,) A client of the 


ae e subsystem facade 


3} Your client code now calls 
methods on the home theater 

Facade, not on the subsystem. 
So now to watch a movie we just 
call one method, watchMovie(), 
and it communicates with the 
lights, DVD player, projector, 
amplifier, screen, and popcorn 
maker for us. 


T've got to have my 
low-level access! 


4) bie Facade still leaves the subsystem 
ney te to be used directly. If you 
_ oe r e advanced functionality 


of 
Lhe Rushmore High School ey partials Classes, they are 
A/V Science Club. e for your use. 
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facade versus adapter 


pum 


Q: If the Facade encapsulates the 
subsystem classes, how does a client 
that needs lower-level functionality gain 
access to them? 


A: Facades don’t “encapsulate” the 
subsystem classes; they merely provide a 
simplified interface to their functionality. The 
subsystem classes still remain available 

for direct use by clients that need to use 
more specific interfaces. This is a nice 
property of the Facade Pattern: it provides 

a simplified interface while still exposing the 
full functionality of the system to those who 
may need it. 


Q: Does the facade add any 
functionality or does it just pass through 
each request to the subsystem? 


A: A facade is free to add its own 
“smarts” in addition to making use of the 
subsystem. For instance, while our home 
theater facade doesn’t implement any new 
behavior, it is smart enough to know that the 
popcorn popper has to be turned on before it 
can pop (as well as the details of how to turn 
on and stage a movie showing). 


Q: Does each subsystem have only 
one facade? 


Not necessarily. The pattern 
certainly allows for any number of facades to 
be created for a given subsystem. 
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thereyareno 
1b Questions 


Q: What is the benefit of the facade 
other than the fact that | now have a 
simpler interface? 


A: The Facade Pattern also allows 
you to decouple your client implementation 
from any one subsystem. Let’s say for 
instance that you get a big raise and decide 
to upgrade your home theater to all new 
components that have different interfaces. 
Well, if you coded your client to the facade 
rather than the subsystem, your client code 
doesn’t need to change, just the facade 
(and hopefully the manufacturer is supplying 
that!). 


Q: So the way to tell the difference 
between the Adapter Pattern and the 
Facade Pattern is that the adapter wraps 
one class and the facade may represent 
many classes? 


A: No! Remember, the Adapter Pattern 
changes the interface of one or more 
classes into one interface that a client is 
expecting. While most textbook examples 
show the adapter adapting one class, you 
may need to adapt many classes to provide 
the interface a client is coded to. Likewise, 
a Facade may provide a simplified interface 
to a single class with a very complex 
interface. 


The difference between the two is not in 
terms of how many classes they “wrap,” it 
is in their intent. The intent of the Adapter 
Pattern is to alter an interface so that it 
matches one a client is expecting. The 
intent of the Facade Pattern is to provide a 
simplified interface to a subsystem. 


A facade not 
only simpliGes 
an interface, it 
decouples a client 
from a subsystem 
of components. 


Facades and 


adapters may 
wrap multiple 
classes, but a 
facade’s intent is 
to simplify, while 
an adapters 

is to convert 

the interface 


to something 
different. 


the adapter pattern 


Constructing your home theater facade 


Let’s step through the construction of the HomeTheaterFacade: The 
first step 1s to use composition so that the facade has access to all the 
components of the subsystem: 


public class HomeTheaterFacade { Here's the Composition; these 
Amplifier amp; 


are all the Components of the 
Tuner tuner; : 15 use. 
DvdPlayer dvd; subsystem we are going 
CdPlayer cd; 
Projector projector; 
TheaterLights lights; 
Screen screen; 


PopcornPopper popper; 


public HomeTheaterFacade (Amplifier amp, 
Tuner tuner, 
DvdPlayer dvd, 
CdPlayer cd, 


Projector projector, The facade is passed a 
Screen screen, reference to each Component 
TheaterLights lights, of the subsystem in its 
PopcornPopper popper) { tonstructor. The facade 


then assigns each to the 


enon = aMle corresponding instance variable. 


this.tuner = tuner; 
this.dvd = dvd; 

this.cd = cd; 
this.projector = projector; 
this.screen = screen; 
this.lights lights; 
this.popper = popper; 


// other methods here ie 


We've just about to fill these j 


n... 
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implementing facade 


Implementing the simplified interface 


Now it’s time to bring the components of the subsystem together into a unified interface. 
Let’s implement the watchMovie() and endMovie() methods: 


public void watchMovie(String movie) { 
System.out.printin(“Get ready to watch a movie...”); 
popper.on(); 


pie eee ae : watehMoviel) follows the same sequence 
eat down (); i, we had to do by hand before, but x 
projector.on(); it up ina handy method that does et 
projector.wideScreenMode () ; the work. Notice that for each oe we 
amp.on(); are delegating the responsibility to the 


amp .setDvd (dvd) ; corresponding Component in the subsystem. 
amp.setSurroundSound (); 
amp.setVolume (5) ; 
dvd.on(); 
dvd.play (movie) ; 
} 


public void endMovie() { 
System.out.printin(“Shutting movie theater down...”); 
popper.off(); 
lights.on(); 


screen.up(); ———, : 
projector.off(); ‘And endMovie() takes care 


amp.off(); : shutting everything down 
dvd.stop(); or us. Again, each task is 
dvd.eject(); delegated to the appropriate 
dvd.off(); Component in the subsystem. 


QB RAWN 
POWER 


Think about the facades you’ve encountered in the Java API. 
Where would you like to have a few new ones? 
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Time to watch a movie (the easy way) 


It’s SHOWTIME! 


Here we're creating the components 


public class HomeTheaterTestDrive { _/ right in the test drive. Normally the 
{ 


. . . ? 
public static void main(String[] args) client is given a facade, it doesn't have 
// instantiate components here to construct one itself. 


HomeTheaterFacade homeTheater = 
new HomeTheaterFacade (amp, tuner, dvd, cd, <~~ First You instantiate 
projector, screen, lights, popper); the Facade with all the 
components in the subsystem. 


homeTheater.watchMovie (“Raiders of the Lost Ark”); 


emenneste ener es Use the simplified interface to 
; first start the movie up, and 
then shut it down. 


File Edit Window Help SnakesWhy’'dltHaveToBeSnakes? 


Here’ 
e's the output, %java HomeTheaterTestDrive 
F ) 
Calling the Fatade’s Get ready to watch a movie... 
watchMovie() does all Popcorn Popper on 
this work for Us... Popcorn Popper popping popcorn! 


Theater Ceiling Lights dimming to 10% 
eae Theater Screen going down 
Top-O-Line Projector on 
Top-O-Line Projector in widescreen mode (16x9 aspect ratio) 
Top-O-Line Amplifier on 
Top-O-Line Amplifier setting DVD player to Top-O-Line DVD Player 
Top-O-Line Amplifier surround sound on (5 speakers, 1 subwoofer) 


Top-O-Line Amplifier setting volume to 5 
Top-O-Line DVD Player on 
Top-O-Line DVD Player playing “Raiders of the Lost Ark” 
Shutting movie theater down... 
and here, we're done cr Popcorn Popper off 
watching the movie, so Theater Ceiling Lights on 
ealling endMoviel) turns Theater Screen going up 


everything of f. _y Top-O-Line Projector off 
Top-O-Line Amplifier off 
Top-O-Line DVD Player stopped “Raiders of the Lost Ark” 
Top-O-Line DVD Player eject 
Top-O-Line DVD Player off 


Q 


2 


fo} 
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facade pattern defined 


Facade Pattern defined 


To use the Facade Pattern, we create a class that simplifies and unifies a set of more 

complex classes that belong to some subsystem. Unlike a lot of patterns, Facade is fairly 
straightforward; there are no mind bending abstractions to get your head around. But that 
doesn’t make it any less powerful: the Facade Pattern allows us to avoid tight coupling between 
clients and subsystems, and, as you will see shortly, also helps us adhere to a new object 
oriented principle. 


Before we introduce that new principle, let’s take a look at the official definition of the pattern: 


The Facade Pattern provides a unified interface to a 
set of interfaces in a subsytem. Facade defines a higher- 


level interface that makes the subsystem easier to use. 


There isn’t a lot here that you don’t already know, but one of the most important things 

to remember about a pattern 1s its intent. This definition tells us loud and clear that the 
purpose of the facade it to make a subsystem easier to use through a simplified interface. 
You can see this in the pattern’s class diagram: 


a Unified interface 


Harry client whose Client Facade that i Is easier to use. 
job just betame : 
¥ ee because of 


the facade- 


That’s it; you’ve got another pattern under your belt! Now, it’s time for that new OO principle. 
Watch out, this one can challenge some assumptions! 
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The Principle of Least Knowledge 


The Principle of Least Knowledge guides us to reduce the 
interactions between objects to just a few close “friends.” 
The principle is usually stated as: 


Design Principle 


Principle of Least Knowledge 
- talk only to your immediate 
friends. 


But what does this mean in real terms? It means when you 
are designing a system, for any object, be careful of the 
number of classes it interacts with and also how it comes to 
interact with those classes. 


This principle prevents us from creating designs that have 

a large number of classes coupled together so that changes 
in one part of the system cascade to other parts. When you 
build a lot of dependencies between many classes, you are 
building a fragile system that will be costly to maintain and 
complex for others to understand. 


WAI 
A Ow CHR bow many classes is this code coupled to? 


public float getTemp() { 


return station.getThermometer() .getTemperature () ; 


} 
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principle of least knowledge 


How NOT to Win Friends and Influence Objects 


Okay, but how do you keep from doing this? The principle 
provides some guidelines: take any object; now from any 


a 
method in that object, the principle tells us that we should khese ayidelines kell eae 
only invoke methods that belong to: Notice gant ie pyects a asl! 
\\ metho «other me 
= The object itself J ” ae! from talling ° 
re 
=~ Objects passed in as a parameter to the method pitts a object that is 
. A\S mn n 
= Any object the method creates or instantiates Think of a “compo stance variable: In other 
: referenced by ann HAS. h relationshiy- 
= Any components of the object words think of this as 4 AS- 


This sounds kind of stringent doesn’t it? What’s the harm in 
calling the method of an object we get back from another 
call? Well, if we were to do that, then we’d be making a 
request of another object’s subpart (and increasing the 
number of objects we directly know). In such cases, the 
principle forces us to ask the object to make the request for us; 
that way we don’t have to know about its component objects 
(and we keep our circle of friends small). For example: 


public float getTemp() { 


Without the Thermometer thermometer = station.getThermometer () ; 
Principle return thermometer.getTemperature () ; 
} 
Here we get the thermometer object 
from the station and then call the 
get Temperature() method ourselves. 
With the public float getTemp() { 
Principle return station.getTemperature () ; 
} 


When we apply the’principle, we add a method 
to the Station class that makes the request 
ko the thermometer for us. This reduces the 
number of classes we're dependent on. 
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Keeping your method calls in bounds... 


Here’s a Car class that demonstrates all the ways you can call methods and still 


adhere to the Principle of Least Knowledge: 


public class Car { 
Engine engine; 


a 


component of 


Here's a We ean Call 


his class- 
rts methods- 


// other instance variables 


public Car() { 
// initialize 


} 


public void start (Key key) 


Doors doors = 


boolean authorized = 


the adapter pattern 


Here we're Creating a new 


engine, etc. 


{ 


new Doors(); 


key.turns(); 


(authorized) { 


engine 


Start)? 


updateDashboardDisplay(); 


} 


doors.lock(); 


You tan call 
component 


object, its methods are legal. 


You ean call a method 
on an object passed as 
a parameter. 


a method on a 
of the object: 


You tan call a lotal method 
within the object. 


You ¢an ¢all a method on an 
object you create or instantiate. 


public void updateDashboardDisplay() { 
// update display 


} 


Q: There is another principle called 
the Law of Demeter; how are they 
related? 


A: The two are one and the same 

and you'll encounter these terms being 
intermixed. We prefer to use the Principle of 
Least Knowledge for a couple of reasons: (1) 
the name is more intuitive and (2) the use of 
the word “Law” implies we always have to 


there are_no 


Dumb Questions 


apply this principle. In fact, no principle is a 
law, all principles should be used when and 
where they are helpful. All design involves 
tradeoffs (abstractions versus speed, space 
versus time, and so on) and while principles 
provide guidance, all factors should be taken 
into account before applying them. 


+ Are there any disadvantages 
to applying the Principle of Least 
Knowledge? 


A: Yes; while the principle reduces 
the dependencies between objects and 
studies have shown this reduces software 
maintenance, it is also the case that 
applying this principle results in more 
“wrapper” classes being written to handle 
method calls to other components. This 
can result in increased complexity and 
development time as well as decreased 
runtime performance. 
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violating the principle of le: 


Ge Sharpen your pencil 
al 


Do either of these classes violate the Principle of Least Knowledge? 
Why or why not? 


public House { 
WeatherStation station; 


// other methods and constructor 


public float getTemp() { 
return station.getThermometer().getTemperature (); 


} 


public House { 
WeatherStation station; 


// other methods and constructor 
public float getTemp() { 


Thermometer thermometer = station.getThermometer (); 
return getTempHelper (thermometer) ; 


= 


public float gett 
return thermometer.geti 


mpHelper (Thermometer thermometer) { 
Temperature (); 


} 


HARD HAT AREA, WATCH OUT 
FOR FALLING ASSUMPTIONS 


WAL 
POWER 


Can you think of a common use of Java that violates the Principle of Least Knowledge? 


Should you care? 


&()ujjud'jno'wa}shs jnoge MOH :JeMsuUy 
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The Facade and the Principle of Least Knowledge 


e friend} 


- This thient only has ae i" 
th brome Theateraca e. ue 
00 rogirarnmnindy having, ae ° 

fa is a GOOD Lhing. 


Client 


The Home TheaterFacade 
manages all those subsystem 


we 


components for the client. 
It keeps the client simple 
and flexible. 


HomeTheaterFacade 


watchMovie() 
endMovie() 
listenToCd() 
endCd() 
listenToRadio() 


endRadio() 


7 \\ 


ne home - 
We ¢an upgrade ks withou WA oar S 
cdPlayer 
theater Compare” z 
vent a 
ce cind, the cliew Tuner setCd() 
arve ampli setDvdl) > DvdPlayer 
setStereoSound() amplier 
a setSurroundSoud() 
ey setTiner) on) 
end setVolume() off) 
setFm() eject() 
setFrequency() pause() 
ae: 
play() 
‘setSurroundAudio( 
er | CdPlayer tain 
[amir StS~*~=«*« ston() 
a Screen oni) 
up() off) 
ject( 
dheving, te une rt 
ko keep subsystems a 
“ \ of Least Knowledge as stop() Projector 
WiPle L_| dvaPlayer 
the Princip lex and too 7 
ell \f this gets too cork tan PopcornPopper 0 
well- , : : we tvMode() 
an Sviends are sees £ cm ot TheaterLights waeeceemniede) 
™ Ol pont) 
‘acades 


introduce additional 


layers of subsystems: 
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your design toolbox 


Tools for your Design Toolbox 


Your toolbox is starting to get heavy! In this 
chapter we’ve added a couple of patterns that 
allow us to alter interfaces and reduce coupling 
between clients and the systems they use. 


OO Principles 


E capsviate what varies 
‘W 


9 inh 
composition lem 


not 


evitante 


Favor 


Program to inberkaces 
tations 


ooselY coupled deesians 
etts that anteratt 


for extension 


amyl eme! 


Shrive Lor \ 
between ob) 


nique 
hpould be oRer pene 


ty 
We have 3 new ie \evel 


Classes 5! aol wie 
but tlosed xo" modifica a Lor maintarnnd we designs: 
Lattions: Do not ¢ coupling in ow fo your 
Devend on a 45 i ber talk onl Y 
tretions (remem ly 
depend on £0" ) 
friends friends Mi 
to you" 
Orly talk 


and TWO new patterns. 
Each changes an interface, 

| the adapter to convert 

and the facade to unify 


“AL am 7 Te » a ei da Th lif 
SS eK All = cm-l an Define an ‘ and simplixy 
ev nN L) Metho - ree ; 
é ¢ Pal Fata eee rare zi / 
ah D wm a oT one c. pane lobes a a 
‘ mae 
oe C verts the anterkace of m2 may 
— Lon i 
Adapter gnother inter kate we : ee scat 
ay 
a ah Ww Leks classes ae 2 if of Facade = ears a ue ne 
be ) etau' i i 
ee couldnt aes fo a set i a cae eal rterfate 
v1, wherkates: & 
aie : oe ae subsystem easier 
mi 


———— 
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BULLET os 


When you need to use an 
existing class and its interface 
is not the one you need, use an 
adapter. 


When you need to simplify 

and unify a large interface or 
complex set of interfaces, use a 
facade. 


An adapter changes an 
interface into one a client 
expects. 


A facade decouples a client 
from a complex subsystem. 


Implementing an adapter may 
require little work or a great deal 
of work depending on the size 
and complexity of the target 
interface. 


Implementing a facade requires 
that we compose the facade 
with its subsystem and use 
delegation to perform the work 
of the facade. 


There are two forms of the 
Adapter Pattern: object and 
class adapters. Class adapters 
require multiple inheritance. 


You can implement more than 
one facade for a subsystem. 


An adapter wraps an object to 
change its interface, a decorator 
wraps an object to add new 
behaviors and responsibilities, 
and a facade “wraps” a set of 
objects to simplify. 


the adapter pattern 


RS Yes, it’s another crossword. All of the solution words are from this chapter. 


1 2 


a _ 
a SERRE 


eT TT 


rT 


PET 


a a 
a 6m CU 


| 


Across Down 
1. True or false, Adapters can only wrap one 2. Decorator called Adapter this (3 words) 
object 3. One advantage of Facade 


5. An Adapter an interface 

6. Movie we watched (5 words) 

10. If in Europe you might need one of these 
(two words) 

11. Adapter with two roles (two words) 

14. Facade still low level access 
15. Ducks do it better than Turkeys 

16. Disadvantage of the Principle of Least 
Knowledge: too many 

17.A simplifies an interface 
19. New American dream (two words) 


4. Principle that wasn't as easy as it sounded 
(two words) 

7.A adds new behavior 

8. Masquerading as a Duck 

9. Example that violates the Principle of Least 
Knowledge: System.out. 
12. No movie is complete without this 

13. Adapter client uses the interface 
18. An Adapter and a Decorator can be said to 


____ an object 
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exercise solutions 


@qsharpen your pencil —§ 
Let's say we also need an adapter that converts a Duck to a Turkey. 
Let's call it DuckAdapter. Write that class: 


we are adapting le 
SD dks, so we implemen 
Mw 
xererse public class DuckAdapter implements Turkey { 


Duck duck; 
Random rand; 


S lati ; We stash a reference to the Duck we are adapting. 
O O public DuckAdapter (Duck duck) { 
= 


this.duck = duck; 
rand = new Random(); 
} Se We also recreate a random object; 
take a look at the fly) method 


public void gobble() { 


duck. quack () ; Te see how it is used. 
} A gobble just becomes a quack. 


public void fly() { 
if (rand.nextInt(5) == 0) { 


duck. fly () 7 
} 
hi 
: —— Ginte ducks Aly a lot longer . an 


turkeys, we decided to only 


duek on average one of five times: 


@qdharpen your pencil 
Do either of these classes violate the Principle of Least Knowledge? 
= For each, why or why not? 


public House { 
WeatherStation station; 


// other methods and constructor 


public float getTemp() { 
return station.getThermometer().getTemperature(); 


} es ee 


Least Ynowlede! 


Violates tre eel of an yet 


public House { 
WeatherStation station; 


// other methods and constructor 


public float getTemp() { 
Thermometer thermometer = station.getThermometer (); 
return getTempHelper (thermometer) ; 


} 


public float getTempHelper (Thermometer thermometer) { 
return thermometer.getTemperature (); 


} 


nciple of Least Knowledge! 
king, our WAY around the 
nged since we 
ve method? 


Doesn't violate Pri 
This seems like hae 

inciple. Has anything, veally cha 
‘ d out the call to another 


just move 


272 Chapter 7 


the adapter pattern 


SLB Exercise solutions 


You've seen how to implement an adapter that adapts an Enumeration to an 
Iterator; now write an adapter that adapts an Iterator to an Enumeration. 


public class IteratorEnumeration implements Enumeration { 
Iterator iterator; 


public IteratorEnumeration(Iterator iterator) { 
this.iterator = iterator; 


public boolean hasMoreElements() { 
return iterator.hasNext (); 


public Object nextElement () 
return iterator.next(); 


WHS BOA WUAT? 


Match each pattern with its intent: 


Pattern Intent 


Convert one interface to 


oer anether 


Adapter Don't alter interface, but add 
responsibility 


Facade ; 
— > Make interface simpler 
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crossword puzzle solution 


SEB Exercise solutions 


GAA 


| Ea 
H Pclo|N|vielal tis Im 

Cc 
Pejalriole|ri{sjolrir|Hje|t lols |rlalel 
a nm 
ff R 
kK Bo 
AN 


[a 
rlwlolw] aly 
14 wi 
meres 
aABAne 


G 
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8 the Template Methed Pattern 


Encapsulating * 
* Algorithms * 


Yeah, he's a great boss until 

it comes to getting down in this 
hole, then it ALL becomes MY job. 
See what I mean? He's nowhere 


in sight! 


We’re on an encapsulation roll; we’ve encapsulated object 
creation, method invocation, complex interfaces, ducks, 
pizzas... what could be next? We're going to get down to encapsulating 
pieces of algorithms so that subclasses can hook themselves right into a computation 
anytime they want. We're even going to learn about a design principle inspired by 
Hollywood. 
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coffee and tea recipes are 


It’s time for some more caffeine 


Some people can’t live without their coffee; some 
people can’t live without their tea. The common 
ingredient? Caffeine of course! 


But there’s more; tea and coffee are made in very 
similar ways. Let’s check it out: 


. Coffer Recivt 
SyarbouZZ Gof e&~ The vetipe Boe 
xr 


tex toffee looks a lot 
like the recipe for 
mk eA tea, doesn't it? 


15% 
pe keP 
jould 

5 and § 
coffee trade ee 
al. 
s are starbort actly confident * 
s 


pil recipe 
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Whipping up some coffee and tea classes 
(in Java) 


Let’s play “coding barista” and write 
some code for creating coffee and tea. 


Here’s the coffee: 


Here's our Coffee class for making coffee. 


ei 


public class Coffee { 


Jemented as 
void sneer oa Eath of the steps is mP 


boilWater ( ‘ panes method: 
prerGoffeeGrinds 
pourlInCup ( 


ee een 
} 


public void boilWater() { £ thods 

System.out.printlin(“Boiling water”); Ti Eath o ice 
implements one step 
the algorithm. There’s 


} 


public void brewCoffeeGrinds() { a method te boil water, 
System.out.printlin(“Dripping Coffee through filter” brew the coffee, pour 

} er the toffee in a cup and 
add sugar and milk. 

public void pourtInCup() { — 3 
System.out.printin(“Pouring into cup”); 


} 
public void addSugarAndMilk() { 


System.out.printlin(“Adding Sugar and Milk”); 
} 
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tea implementation 


and now the Tea... 


278 


This looks very similar to the 


eee = one we just implemented in 
eee ae Coffee; the second and fourth 
wei. peepameneeine 4 steps are different, but it’s 
boilWater(); basically the same recipe. 


steepTeaBag(); 
pourInCup (); 
addLemon (); 


} 


public void boilWater() { 


System.out.println (“Boiling water”); — S 
} 


public void steepTeaBag() { 


Syst t intln (“St i the t 1S > These a 
ystem.out.printin eeping € tea); methods are 
spetialized to 

public void addLemon() { Tea. 


System.out.printlin(“Adding Lemon”) ; ed 
} 


public void pourInCup() { 
System.out.println(“Pouring into cup”); 


Notice that 
these two 
methods are 
exattly the 
same as they are 
in Coffee! So 
we definitely 
have some code 
duplication going, 


on here. 


} ce 


When we've got code 
duplication, that's a good sign 
we need to clean up the design. It 
seems like here we should abstract 
the commonality into a base class 
since coffee and tea are so 
similar? 


Chapter 8 


the template method pattern 


ae ° 
fa7S Design Puzzle 


You've seen that the Coffee and Tea classes have a fair bit of code duplication. Take 


another look at the Coffee and Tea classes and draw a class diagram showing how you’d 
redesign the classes to remove redundancy: 


first cut at abstraction 


Sir, may | abstract your Coffee, Tea? 


It looks like we’ve got a pretty straightforward design 
exercise on our hands with the Coffee and Tea classes. 
Your first cut might have looked something like this: 


; InCup() 
Th boilWater() and pour 
elds are shared by both subclasses, 
so they are defined in the superclass- 


CaffeineBeverage 


The PrepareRecipe() method | ed prepareRecipe() 


differs in each subélass, so it is eae: 
defined as abstract. pourlnCup() 


Each subelass oN, Coffee Tea Each subelass ie 

implements its prepareRecipe() prepareRecipe() the PrepareRecipe ) 

own recipe. brewCoffeeGrinds() steepTeaBag() method and implements 
addSugarAndMilk() addLemon() its own recipe. 


etifie to Coffee 


The methods SP he gubclasses: 


and Tea stay * 


QB RAWN 
POWER 


Did we do a good job on the redesign? Hmmmam, take another look. Are we overlooking some other 
commonality? What are other ways that Coffee and Tea are similar? 
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the template method pattern 


Taking the design further... 


So what else do Coffee and Tea have in common? Let’s start with 
the recipes. 


e wa water 
() Boil efee in poiling 
Brew cup 
a pour cof Seek 
(ay aad Suset > Starbuzz Tea Recipe 


(1) Boil some water 

(2) Steep tea in boiling water 
(3) Pour tea in cup 

(4) Add lemon 


Notice that both recipes follow the same algorithm: 


@ Boil some water. 


These aren't These two are 
© Use the hot water to extract the coffee abstracted, but ae siveady abstracted 
the same, they jus ¥ base class. 
or tea. orth ey alleen to the base 
beverages: 


© Pour the resulting beverage into a cup. 


© Add the appropriate condiments to the 
beverage. 


So, can we find a way to abstract prepareRecipe() too? Yes, let’s find out... 
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abstract the algorithm 


Abstracting prepareRecipel() 


Let’s step through abstracting prepareRecipe() 
from each subclass (that is, the Coffee and Tea 
classes)... 


The first problem we have is that Coffee uses brewCoffeeGrinds() and 
addSugarAndMilk() methods while Tea uses steep TeaBag() and addLemon() 
methods. 


Coffee Tea 
void prepareRecipe() { void prepareRecipe() { 
boilWater(); boilWater(); 
brewCoffeeGrinds (); | <a ae steepTeaBag () ; 
pourlinCup(); pourlInCup (); 


addSugarAndMilk();. ¢——@-7-‘\——»._ addllemon(); 
} 


Let’s think through this: steeping and brewing aren’t so different; they’re pretty analogous. 
So let’s make a new method name, say, brew(), and we’ll use the same name whether 
we’re brewing coffee or steeping tea. 


Likewise, adding sugar and milk is pretty much the same as adding a lemon: both 
are adding condiments to the beverage. Let’s also make up a new method name, 
addCondiments(), to handle this. So, our new prepareRecipe() method will look like this: 


void prepareRecipe() { 
boilWater(); 
brew(); 


pourInCup (); 
addCondiments () ; 


2) Now we have a new prepareRecipe() method, but we need to fit it into the co 
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de. 
To do this we are going to start with the CaffeineBeverage superclass: ae 


the template method pattern 


CaffeineBeverage is abstract, just 


a like in the Class design. Now, the same prepareRecipel) method will be used 


to make both Tea and Coffee. paar 
detlared final because ‘ don ae ee in 
verride this method an 

final void prepareRecipe() { @———_ to be greene steps 2 and 4 to brew() 
DoeiWee ee |e ee a ddCondiments(). 

brew(); the beverage and a 

pourtInCup (); 

addCondiments(); 


public abstract class CaffeineBeverage { 


} 
Because Coffee and Tea handle these methods 
spel ac a Nee PA a in different ways, they're going to have to be 


+" detlared as abstract. Let the subclasses worry 


abstract void addCondiments(); 


about that stuff! 
void boilWater() { 
System.out.printlin (“Boiling water”) ; Resewber; wa moved hese tds 
the CaffeineBeverage ¢lass (back 
void pourinCup() { oa in our élass diagram). 


System.out.println (“Pouring into cup”); 
} 
} 


rs) Finally we need to deal with the Coffee and Tea classes. They now rely on 
CaffeineBeverage to handle the recipe, so they just need to handle brewing and 


condiments: 
G in our design, Tea and Coffee now 


ei eBevera e. 
public class Tea extends CaffeineBeverage { extend Catt " : 
public void brew() { 


System.out.printlin(“Steeping the tea”); 
} 


public void addCondiments() { a Tea needs to define brew) and 
System.out.printlin(“Adding Lemon”) ; addCondiments) — the two abstract 
} : methods from Beverage. 


Came for Coffee, except Coffee deals 


with coffee, and sugar and milk instead 
of tea bags and lemon. 
public class Coffee extends CaffeineBeverage { 


public void brew() { 


System.out.printlin(“Dripping Coffee through filter”); 
} 


public void addCondiments() { 


System.out.println(“Adding Sugar and Milk”); 
} 


youarehere > 283 


class diagram for 


Draw the new class diagram now that we’ve moved the 
implementation of prepareRecipe() into the CaffeineBeverage class: 


G harpen our pencil 
~ y 
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What have we done? 


Tea 


@ Boil some water 


@ Steep the te 


© Pov xea ina cup 


@ Add lemon 


generalize 


relies on 
subclass for 


me st 
Tea suotlass eens eke 


ae, 
© Steep the teabag in the water 
© Add lemon 


itself, but 
steps | and > 
velies on Tea or Coffee to 
do steps 2 and . 


We've recognized that 


the two recipes are 
essentially the same, 
although some of the 


steps require different 


implementations. So 

we've generalized the 

recipe and placed it in 
the base ¢lass. 


abag in she water 


Caffeine Beverage 


@ Boil some water 


© Brew 


© Pour beverage in a cup 
@ Add condiments 


f 


Caffeine Beverage knows 


and tontrols the steps of 


the vetipe and performs 


the template method pattern 


Cof fee 


@ Foi SOme Water 


12) 
i Brew the Coffee Irinds 
Pour cot foo ; 
tfee in a cup 


O ha Sugar ang milk 


generalize 


relies on 
subclass for 
some steps C 

offes Subelac. 


— 


@ brew the coffee grinds 
@ Add sugar and milk 
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meet the femplate method pattern 


Meet the Template Method 


We've basically just implemented the Template Method Pattern. What’s that? Let’s look 
at the structure of the CaffeineBeverage class; it contains the actual “template method:” 


prepareRecipel) is our template method. 
Why? 


public abstract class CaffeineBeverdge { 
Because: 


void final prepareRecipe() { | (1) |t is a method, after all. 


(2) [4 serves as a template for an 


paces seis ed LZ | ait in this case, an algorithm for 
making caffeinated beverages. 


brew (); kK In the template, each step of 
&—— the algorithm is represented 
pourInCup () ; = by a method. 


Some methods are handled 
by this élass... 


addCondiments(); 
--and some are handled 


. a ——\ 
by the subélass. 


abstract void brew() ; a The wethods tisk need to 


abstract void addCondiments () ; be supplied by a subclass ave 
declared abstract. 


void boilWater() { 
// implementation 


} 


void pourInCup() { 
// implementation 


} 


The Template Method de@nes the steps of an algorithm and allows 


subclasses to provide the implementation for one or more steps. 
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Let’s make some tea... 


Let’s step through making a tea and trace through 
how the template method works. You'll see that 
the template method controls the algorithm; at 
certain points in the algorithm, it lets the subclass 
supply the implementation of the steps... 


Behind 
the Scenes 


boilWater (); 
1) Okay, first we need a Tea object... brew (); 


pourtInCup (); 


Tea myTea = new Tea(); addCondiments(); 


2 ) Then we call the template method: The prepareRetipel ) 
method controls the 
myTea.prepareRecipe (); algorithm, no one Can 


change this, and it 


which follows the algorithm for making caffeine 
beverages... 


Lounts on subtlasses to 
provide some or all of 


the implementation. 


3) First we boil water: 


boilWater (); OE ae 


which happens in CaffeineBeverage. 


4) Next we need to brew the tea, which only the subclass knows 
how to do: 


brew(); OO 


5 ) Now we pour the tea in the cup; this 1s the same for all beverages so it 
happens in CaffeineBeverage: 


pourtInCup () ; 


6 } Finally, we add the condiments, which are specific to each beverage, so 
the subclass implements this: 


addCondiments (); 


CaffeineBeverage 


prepareRecipe() 
boilWater() 
pourlnCup() 


Tea 


brew() 
addCondiments(); 
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what did template method get us? 


What did the Template Method get us? 
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e 


Underpowered Tea & Coffee 
implementation 


Coffee and Tea are running the show; 
they control the algorithm. 


Code is duplicated across Coffee and 
Tea. 


Code changes to the algorithm 
require opening the subclasses and 
making multiple changes. 


Classes are organized in a structure 
that requires a lot of work to adda 
new caffeine beverage. 


Knowledge of the algorithm and how 
to implement it is distributed over 
many classes. 


New, hip CaffeineBeverage 
powered by Template Method 


The CaffeineBeverage class runs 
the show; it has the algorithm, and 
protects it. 


The CaffeineBeverage class 
maximizes reuse among the 
subclasses. 


The algorithm lives in one place and 
code changes only need to be made 
there. 


The Template Method version provides 
a framework that other caffeine 
beverages can be plugged into. New 
caffeine beverages only need to 
implement a couple of methods. 


The CaffeineBeverage class 
concentrates knowledge about the 
algorithm and relies on subclasses to 
provide complete implementations. 


the template method pattern 
Template Method Pattern defined 


You’ve seen how the Template Method Pattern works in our Tea and Coffee example; 
now, check out the official definition and nail down all the details: 


The Template Method Pattern defines the skeleton 
of an algorithm in a method, deferring some steps to 


subclasses. ‘Template Method lets subclasses redefine 


certain steps of an algorithm without changing the 
algorithm’s structure. 


This pattern is all about creating a template for an algorithm. What’s a template? 
As you've seen it’s Just a method; more specifically, it’s a method that defines an 
algorithm as a set of steps. One or more of these steps is defined to be abstract and 
implemented by a subclass. This ensures the algorithm’s structure stays unchanged, 
while subclasses provide some part of the implementation. 


Let’s check out the class diagram: 
The template method makes use of the 
PrimitiveOperations to implement an 


algorithm. [t is decoupled from the actual 
implementation of these operations. 


The AbstractClass - 


contains the template 
method. AbstractClass 

primitiveOperation1(); 
and abstract versions templateMethod() -+++eeeeeeeeeeePbeeee eee ee wees 


primitiveOperation2(); 


of the operations used —_—~ 7 primitiveOperation1() 


primitive Operation2() 


in the template method. 


ConcreteClass 


primitiveOperation1() > . 
There m3 be mary h yee primitiveOperation2() The ConereteClass implements 


Classes © of the abstract operations, 
concn" nek a i which ave called when the 
pare eens Y templateMethod() needs them. 

Tanlate mnecnoe 
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template method pattern up close 


ZX Cade Up Clase 


Let’s take a closer look at how the AbstractClass is defined, including the template method 
and primitive operations. 


Here we have our abstract class; it 

is declared abstract and meant te 

be subelassed by classes that provide 

implementations of the operations: a 7 oat a " 
declared final to prevent subtlasses 
from reworking the sequence 


steps in the algorithm. 


abstract class AbstractClass { 


final void templateMethod() { The template method 


primitiveOperationl () ; defines the sequence of 
primitiveOperation2 () ; $ er steps, each represented 


concreteOperation () ; by a method. 


} 


abstract void primitiveOperation1 () ‘ 


abstract void primitiveOperation2 () ; 


In this example, two of 


void concreteOperation() { the Primitive operations 
// implementation here must be implemented b 
} tonérete subclasses. 


We also have a Contrete operation defined 
in the abstract class. More about these 
kinds of methods in a bit... 
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Code Way Up Close 


Now we're going to look even closer at the types of method that can go in the abstract class: 


We've changed the . 
emplateMethod to include 
3a new method call. 


abstract class AbstractClass { 


final void templateMethod() { 

primitiveOperation1 () ; 

primitiveOperation2 () ; We still have our primitive 
concreteOperation () ; methods; these are 
neok() abstract and implemented 


} 
by contrete subclasses. 


abstract void primitiveOperation1 () ; 


renee Wane ore ee A contrete operation is defined in the 
abstract class. This one is declared 


final void concreteOperation() { pee Baal so that subelasses tan't override it. 
in 


// implementation here 


[t may be used in Lhe template method 
| directly, or used by subclasses. 


void hook() {} 


A tontvele wethod tek We éan also have contrete methods that do nothing by 
hs Pctes (a thing] a default; we call these “hooks.” Subtlasses ave free to 
override these but don’t have to. We're going, to see 


how these are useful on the next page. 
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implement a hook 


Hooked on 
Template Method... 


A hook is a method that 1s declared in the 
abstract class, but only given an empty 

or default implementation. This gives 
subclasses the ability to “hook into” the 
algorithm at various points, if they wish; a 
subclass is also free to ignore the hook. 
There are several uses of hooks; let’s take 


a look at one now. We'll talk about a few 
other uses later: 


With a hook, I can override 

the method, or not. It's my choice. 
If I don't, the abstract class 

provides a default implementation. 


public abstract class CaffeineBeverageWithHook { 


void prepareRecipe() { 
boilWater(); 
brew(); 
pourtInCup () ; 


if (customerWantsCondiments () ) 


addCondiments () ; 
} 
} 


abstract void brew(); 


abstract void addCondiments(); 


void boilWater() { 


System.out.printlin(“Boiling water”); 


} 


void pourInCup() { 


System.out.printlin(“Pouring into cup”); implementa ne 


} 


boolean customerWantsCondiments () 


return true; 


} 
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tle tonditional statement 


ve added a lit | 
—_ ser een its suecess on a tonerete method 
vuctomerWantsCondiments() \f£ the 


customer WANTS tondiments, 
we call addCondiments(). 


only then do 


Here we ve defined a method 


‘ m \ ) iA) +t) default 
with a ( ostly en stned just 


returns true and does nothing, else: 


This is a hook because the 
subélass can override this 
method, but doesn’t have to. 


the template method pattern 


Using the hook 


To use the hook, we override it in our subclass. Here, the hook controls whether 
the CaffeineBeverage evaluates a certain part of the algorithm; that is, whether 
it adds a condiment to the beverage. 


How do we know whether the customer wants the condiment? Just ask ! 


public class CoffeeWithHook extends CaffeineBeverageWithHook { 


public void brew() { 
System.out.printlin(“Dripping Coffee through filter”); 


public void addCondiments() { Here's where 
System.out.printlin (“Adding Sugar and Milk”); Ke hook and provide Your 


own Lunetionality: 


you overvide 


public boolean customerWantsCondiments() { 
String answer = getUserInput(); 


if (answer.toLowerCase().startsWith(“y”)) { 
return true; 


Get the user's input on 


} else { the condiment decision 
return false; T+ and return true or false. 
} depending on the input. 


private String getUserInput() { 
String answer = null; 


System.out.print (“Would you like milk and sugar with your coffee (y/n)? “); 


BufferedReader in = new BufferedReader (new InputStreamReader (System.in)); 
iEey 

answer = in.readLine() ; 
} catch (IOException ioe) { 

System.err.printin(“IO error trying to read your answer”); 


} 
milk and 


iit (amen == inwili)) { “C he'd like , 
are ee ie This code asks the user if the ommand line- 


, sugar and gets his input from 


return answer; 
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test drive 


Let’s run the TestDrive 


Okay, the water’s boiling... Here’s the test code where 
we create a hot tea and a hot coffee 


public class BeverageTestDrive { 
public static void main(String[] args) { 


TeaWithHook teaHook = new TeaWithHook(); as Create a tea. 
CoffeeWithHook coffeeHook = new CoffeeWithHook () ; 


=A toffee. 


System.out.println(“\nMaking tea...”); 
teaHook.prepareRecipe (); 


=~ And call prepareRecipel) on both! 


System.out.println(“\nMaking coffee...”); LL“ 
coffeeHook.prepareRecipe (); 


And let’s give it a run... 


File Edit Window Help send-more-honesttea 


%Sjava BeverageTestDrive 


Making tea... 
Boiling water 
Steeping the tea 


Pouring into cup 
Would you like lemon with your tea (y/n)? y 


Adding Lemon 


A steaming cup of tea, and yes, of 


course we want that lemon! 


eup of coffee, 


istline 


And a nite hot 


Making coffee... but we'll pass on the wa 


Boiling water ‘ 
Dripping Coffee through filter expanding, condiments: 
Pouring into cup 

Would you like milk and sugar with your coffee (y/n)? n 


% 
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+ When I'm creating a template 
method, how do | know when to use 
abstract methods and when to use 
hooks? 


A: Use abstract methods when your 
subclass MUST provide an implementation 
of the method or step in the algorithm. 

Use hooks when that part of the algorithm 

is optional. With hooks, a subclass may 
choose to implement that hook, but it doesn’t 
have to. 


: What are hooks really supposed 
to be used for? 


A: There are a few uses of hooks. As 
we just said, a hook may provide a way for 
a subclass to implement an optional part 


Now, I would have thought 
that functionality like asking the 
customer could have been used by 
all subclasses? 


the template method pattern 


You know what? We agree with you. But you 


have to admit before you thought of that it was a 


pretty cool example of how a hook can be used 


to conditionally control the flow of the algorithm 


in the abstract class. Right? 


We’re sure you can think of many other more 


realistic scenarios where you could use the 


template method and hooks in your own code. 


there are no = 

pum) Questions 
of an algorithm, or if it isn’t important to 
the subclass’ implementation, it can skip 
it. Another use is to give the subclass 
a chance to react to some step in the 
template method that is about to happen, 
or just happened. For instance, a hook 
method like justReOrderedList() allows the 
subclass to perform some activity (such as 
redisplaying an onscreen representation) 
after an internal list is reordered. As you've 
seen a hook can also provide a subclass 
with the ability to make a decision for the 
abstract class. 


Q: Does a subclass have to 
implement all the abstract methods in the 
AbstractClass? 


A: Yes, each concrete subclass defines 
the entire set of abstract methods and 


provides a complete implementation of the 
undefined steps of the template method's 
algorithm. 


Q: It seems like | should keep my 
abstract methods small in number, 
otherwise it will be a big job to implement 
them in the subclass. 


A: That's a good thing to keep in 

mind when you write template methods. 
Sometimes this can be done by not making 
the steps of your algorithm too granular. But 
it's obviously a trade off: the less granularity, 
the less flexibility. 


Remember, too, that some steps will be 
optional; so you can implement these as 
hooks rather than abstract methods, easing 
the burden on the subclasses of your 
abstract class. 


} J aaa Arib nla 
the hollywood principle 


The Hollywood Principle 


We've got another design principle for you; it’s called the 
Hollywood Principle: 


The Hollywood Principle 


Don't call us, we'll call you. 


Easy to remember, right? But what has it got to do with OO 
design? 


The Hollywood principle gives us a way to prevent 
“dependency rot.” Dependency rot happens when you have 
high-level components depending on low-level components 


depending on high-level components depending on sideways 


components depending on low-level components, and so on. 


When rot sets in, no one can easily understand the way a 
system is designed. 


With the Hollywood Principle, we allow low-level components 


to hook themselves into a system, but the high-level 
components determine when they are needed, and how. In 
other words, the high-level components give the low-level 
components a “don’t call us, we'll call you” treatment. 


You've heard me say it 
before, and I'll say it again: 


don't call me, I'll ca 


“oo 


Low-Level 
Component 
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High-Level Component 


Another 
Low-Level 
Component 


when 2 


a Flack 


calls a hi 
directly. 


components t 


Il you! 


But the high-level 


ow vol 


nd how: 


vel Component never 
gh—leve] component 


the template method pattern 


The Hollywood Principle and Template Method 


The connection between the Hollywood Principle and the Template Method Pattern 1s probably somewhat 
apparent: when we design with the Template Method Pattern, we’re telling subclasses, “don’t call us, we'll call 
you.” How? Let’s take another look at our CaffeineBeverage design: 


CaffeineBeverage is ovr eee 
m _ [thas control over the Cl 
i ae the recipe, and calls on the on the Correate will depend 
cubelases only when theyre needed for a abstraction i 
er 
an implementation er ene? ; Concrete Tea o, Coffee ; : 
CaffeineBeverage reduces d e, which 
ePendencies jn the 
prepareRecipe() overall system. 
boilWater() 
pourlnCup() 
brew() 
addCondiments() 


Coffee Tea 
brew() brew() 


addCondiments() addCondiments() 


Tea and Coffee ae 
The sube] all the abstract class 
pases ate us a Gilly without men 


sap d, ed simply tp a 
Provide im in : Ply 
ne aerate _ “palled” first- 


os RAIN 
\ ad Owyv Ec L > What other patterns make use of the Hollywood Principle? 


ésJiaujo Aue ‘ansesqo ‘poujey\| Aiojoe4 ey 
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who does what 


h o 4 
bumb Questions 


Q: How does the Hollywood Principle 
relate to the Dependency Inversion 
Principle that we learned a few chapters 
back? 


A: The Dependency Inversion 
Principle teaches us to avoid the use of 
concrete classes and instead work as 
much as possible with abstractions. The 
Hollywood Principle is a technique for 
building frameworks or components so that 
lower-level components can be hooked 


+ 
*we BaoES WHAT? 


into the computation, but without creating 
dependencies between the lower-level 
components and the higher-level layers. So, 
they both have the goal of decoupling, but 
the Dependency Inversion Principle makes a 
much stronger and general statement about 
how to avoid dependencies in design. 


The Hollywood Principle gives us a 
technique for creating designs that allow 
low-level structures to interoperate while 
preventing other classes from becoming too 
dependent on them. 


+ G&G 


Match each pattern with its description: 


Pattern 


Template Method 


Strategy 


Factory Method 
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Q: Is a low-level component 
disallowed from calling a method in a 
higher-level component? 


A: Not really. In fact, a low level 
component will often end up calling a method 
defined above it in the inheritance hierarchy 
purely through inheritance. But we want to 
avoid creating explicit circular dependencies 
between the low-level component and the 
high-level ones. 


Description 


Encapsulate interchangeable 


behaviors and use delegationto 


decide which behavior to use 


Subclasses decide how 
to implement steps in an 


algorithm 


Subclasses decide which 


concrete classes to instantiate 


Template Methods in the Wild 


The Template Method Pattern is a very common pattern and 
you're going to find lots of it in the wild. You’ve got to have 
a keen eye, though, because there are many implementations 
of the template methods that don’t quite look like the 
textbook design of the pattern. 


This pattern shows up so often because it’s a great design tool 
for creating frameworks, where the framework controls how 
something gets done, but leaves you (the person using the 
framework) to specify your own details about what is actually 
happening at each step of the framework’s algorithm. 


Let’s take a little safari through a few uses in the wild (well, 
okay, in the Java API)... 


the template method pattern 


In training, we study the 
classic patterns. However, 
when we are out in the real world, we 
must learn to recognize the patterns 
out of context. We must also learn 
to recognize variations of patterns, 

because in the real world a square 
hole is not always truly square. 
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sorting with template method 


Sorting with Template Method 


What’s something we often need to do with arrays? 


Sort them! : 
We've pared down this 
Recognizing that, the designers of the Java Arrays class tode a little to make it 
have provided us with a handy template method for es easier to explain. If you'd 
sorting. Let’s take a look at how this method operates: like to see it all, grab 


the source fom Sun and 
We actually have two methods here and they act together to ahetk it ewte~ 
provide the sort funetionality. 


The first methods 
that eveates 3 yy he merge 
ane ane uaa of the array and tells 

SY 


al n 
Habe Oe tat at the est element: 


public static void sort (Object[] a) { 
Object aux[] = (Object[])a.clone(); 
mergeSort (aux, a, 0, a.length, 0); 

} The mergeSort() method contains the sort algorithm, and relies 
on an implementation of the compare Tol) method to complete the 
algorithm. If you're interested in the nitty gritty of how the 
sorting happens, you'll want to check out the Sun source code. 


——, Think of this as the 


private static void mergeSort (Object srce[], Object dest[], template method. 
int low, int high, int off) 
{ 


for (int i=low; i<high; itt) { 


for (int j=i; j>low && 
( (Comparable) dest [j-1]) .compareTo ( (Comparable) dest[j3])>0; j--) 


{ 
swap(dest, j, j-1l); 
} This j a compare Tol) is the method we need 
} ee i ee tontrete method, alread to implement to “Lill out” the 
ere defined in the Arrays ¢lass. template method. 
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We've got some ducks to sort... 


Let’s say you have an array of ducks that you’d like to sort. How 

do you do it? Well, the sort template method in Arrays gives us the 
algorithm, but you need to tell it how to compare ducks, which you do by 
implementing the compareTo() method... Make sense? 


No, it doesn't. Aren't 
we supposed to be 
subclassing something? I thought 

that was the point of Template 
Method. An array doesn't subclass 
anything, so I don't get how we'd 
use sort(). 


ea got an array of 


Ducks we need to sort. 


Good point. Here’s the deal: the designers of sort() wanted it 
to be useful across all arrays, so they had to make sort() a static 
method that could be used from anywhere. But that’s okay, 

it works almost the same as if it were in a superclass. Now, 
here is one more detail: because sort() really isn’t defined in 


our superclass, the sort() method needs to know that you’ve 
implemented the compareTo() method, or else you don’t have 
the piece needed to complete the sort algorithm. 


To handle this, the designers made use of the Comparable 
interface. All you have to do is implement this interface, which 
has one method (surprise): compareTo(). 


What is comparefo()? 


The compareTo() method compares two objects and returns whether one is less than, greater than, 
or equal to the other. sort() uses this as the basis of its comparison of objects in the array. 


I don't know, 
that's what 
compareTo() tells us. 


Am I greater 


than you? 
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implementing comparable 


Comparing Ducks and Ducks 


Okay, so you know that if you want to sort Ducks, 
you're going to have to implement this compare To() 
method; by doing that you’ll give the Arrays class 
what it needs to complete the algorithm and sort your 
ducks. 


Here’s the duck implementation: 


Remember, we need to implement the Comparable 
: a interface since we aren't veally subclassing, 


public class Duck implements Comparable { 
String name; 


int weight; aN Our Ducks have a name and a weight 


public Duck(String name, int weight) { 
this.name = name; 
this.weight = weight; 


| We've keepin’ it simple; all Ducks do 


‘ : “aht! 
public String toString() { he print their name and weight: 
return name + “ weighs “ + weight; 


a Okay, here’s what sort needs... 


public int compareTo(Object object) { 
™~___ compareTo() takes another Duck to compare THIS Duck to. 
Duck otherDuck = (Duck) object; «——— 


} 


if (this.weight < otherDuck.weight) { 


return -1; a Here’s where we specify how Ducks 
} else if (this.weight == otherDuck.weight) { compare. If THIS Duck weighs less 


Pere ee than otherDuck then we return —l; 
} else { // this.weight > otherDuck.weight if they ave equal, sie eebive Or and it 


return 1; 


} THIS Duck weighs more, we return |. 
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Let’s sort some Ducks 


Here’s the test drive for sorting Ducks... 


public class DuckSortTestDrive { 


public static void main(String[] args) { 
Duck[] ducks = { 

new Duck(“Daffy”, 8) 
new Duck (“Dewey”, 2) 
new Duck (“Howard”, 7 
new Duck (“Louie”, 2) 
new Duck(“Donald”, 1 
new Duck (“Huey”, 2) 


Noti¢e that we 

call Arrays’ statie 
method sort, and 
pass it our Ducks. 


\ 7 Arrays.sort (ducks) ; 


System.out.println(“\nAfter sorting:” 
display (ducks) ; 


he 


System.out.printlin(“Before sorting:”) 
display (ducks) ; 


ducks) 
i++ 


public static void display (Duck[] 
for (int i = 0; i < ducks.length; 
System.out.printin(ducks[i]); 


} 
Let the sorting commence! 


the template method pattern 


Let’s print them to see 
their names and weights. 


It’s sort timel 


. Let’s print them (again) to see 
a: their names and weights. 


{ 
){ 


File Edit_Window Help DonaldNeedsToGoOnADiet 


$java DuckSortTestDrive 


Before sorting: 
Daffy weighs 8 
Dewey weighs 2 
Howard weighs 7 
Louie weighs 2 
Donald weighs 10 
Huey weighs 2 


The unsorted Ducks 


After sorting: 
Dewey weighs 2 
Louie weighs 2 
Huey weighs 2 
Howard weighs 7 
Daffy weighs 8 
Donald weighs 10 
% 


The sorted Ducks 
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behind the scenes: sorting ducks 


The making of the sorting duck machine 


Let’s trace through how the Arrays sort() template 
method works. We’ll check out how the template 
method controls the algorithm, and at certain 
points in the algorithm, how it asks our Ducks to 


Behind 
the Scenes 


supply the implementation of a step... See rere here, 
. compareTo () 
- swap () 
& First, we need an array of Ducks: } 
Duck[] ducks = {new Duck(“Daffy”, 8), ... }; 
The sort() method controls 
2 Then we call the sort() template method in the Array the algorithm, no Class can 
class and pass it our ducks: change this. sort() counts 


Arrays.sort (ducks) ; 


The sort() method (and its helper mergeSort()) control 
the sort procedure. 


3) To sort an array, you need to compare two items one 
by one until the entire list is in sorted order. 


When it comes to comparing two ducks, the sort 
method relies on the Duck’s compareTo() method 
to know how to do this. The compareTo() method 
is called on the first duck and passed the duck to be 
compared to: 


ducks [0].compareTo(ducks[1]); 


———F 


First, Duck Duck to compare it to 


(4 If the Ducks are not in sorted order, they’re swapped with 
the concrete swap() method in Arrays: 


swap () ——— 


5 The sort method continues comparing and swapping Ducks 
until the array is in the correct order! 
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on a Comparable class to 
provide the implementation of 
compare Tol) 


Duck 


compareTo() 
toString() 


No inheritance, unlike 
a typical template 
method. 


Arrays 


thereyare no 


DumbQuestions 


©: Is this really the Template 
Method Pattern, or are you trying too 
hard? 


A: The pattern calls for implementing 
an algorithm and letting subclasses supply 
the implementation of the steps — and the 
Arrays sort is clearly not doing that! But, 

as we know, patterns in the wild aren't 
always just like the textbook patterns. They 
have to be modified to fit the context and 
implementation constraints. 


The designers of the Arrays sort() method 
had a few constraints. In general, you can’t 
subclass a Java array and they wanted the 
sort to be used on all arrays (and each array 
is a different class). So they defined a static 
method and deferred the comparison part of 


gL RAN 
POweR 


the algorithm to the items being sorted. 


So, while it’s not a textbook template 
method, this implementation is still in the 
spirit of the Template Method Pattern. Also, 
by eliminating the requirement that you have 
to subclass Arrays to use this algorithm, 
they've made sorting in some ways more 
flexible and useful. 


Q: This implementation of sorting 
actually seems more like the Strategy 
Pattern than the Template Method 
Pattern. Why do we consider it 
Template Method? 


A: You're probably thinking that 
because the Strategy Pattern uses object 
composition. You're right in a way — we're 


the template method pattern 


using the Arrays object to sort our array, so 
that’s similar to Strategy. But remember, 

in Strategy, the class that you compose 
with implements the entire algorithm. The 
algorithm that Arrays implements for sort 

is incomplete; it needs a class to fill in the 
missing compareTo() method. So, in that 
way, it’s more like Template Method. 


Q: Are there other examples of 
template methods in the Java API? 


A: Yes, you'll find them in a few 
places. For example, java.io has a read() 
method in InputStream that subclasses 
must implement and is used by the template 
method read(byte bf], int off, int len). 


We know that we should favor composition over inheritance, right? Well, the implementers of the 
sort() template method decided not to use inheritance and instead to implement sort() as a static 
method that is composed with a Comparable at runtime. How is this better? How is it worse? How 
would you approach this problem? Do Java arrays make this particularly tricky? 


2 
VRAIN 
CGwerR 


, og 


Think of another pattern that is a specialization of the template method. In this specialization, primitive 


operations are used to create and return objects. What pattern is this? 
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the paint hook 


Swingin’ with Frames 


Up next on our Template Method safari... keep your eye out for swinging JFrames! 


If you haven’t encountered JFrame, it’s the most basic Swing container and inherits 
a paint() method. By default, paint() does nothing because it’s a hook! By overriding 
paint(), you can insert yourself into JFrame’s algorithm for displaying its area of the 
screen and have your own graphic output incorporated into the JFrame. Here’s 
an embarrassingly simple example of using a JFrame to override the paint() hook 
method: We're extending JFrame, which contains 
a method update() that controls the 
algorithm for updating, the screen. 
We tan hook into that algorithm by 
overriding the paint () hook method: 


public class MyFrame extends JFrame { 


eo _____ > Door’ look behind the 


public MyFrame (String title) { curtain! Just some 
super (title) ; initialization here... 
this.setDefaultCloseOperation (JFrame.EXIT_ON CLOSE) ; 


this.setSize (300,300); 
this.setVisible (true); 


| FS dF eame’s update algorithm calls paint(). By 


‘ hina... it’s a hook. 
public void paint (Graphics graphics) { default, paint() does = “ es the 
super.paint (graphics) ; We've overriding paint), - " 
Seeing weg = or veleil JFrame to draw a message in the window. 


graphics.drawString(msg, 100, 100); 
} 


public static void main(String[] args) { 


MyFrame myFrame = new MyFrame(“Head First Design Patterns”); 
} 


@ © @ Head First Design Patterns 


Here’s the message that gets 
Eeuled painted in the frame because we ve 
hooked into the paint() method. 
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Applets 


Our final stop on the safari: the applet. 


You probably know an applet is a small program that runs in a web page. Any 
applet must subclass Applet, and this class provides several hooks. Let’s take a look 
at a few of them: 


The init hook allows the applet to do whatever 
it wants to initialize the applet the first time. 
public class MyApplet extends Applet { 

String message; 


vepaint() is a tontrete method in the Applet 


public void init() { 
fetesge = “ae te Woe, Pen ate tlass that lets upper-level components know 
repaint(); the applet needs to be redrawn. 


} 


. . The start hook allows the applet to do 
public void start() { <_< something when the applet is just about 


to be displayed on the web page. 


Ua 


message = “Now I’m starting up...”; 
repaint (); 


} 


public void stop() { cs 


Lo another page the 


message = “Oh, now I’m being stopped...”; \f the user goes rf 
FepeLnet) 7 stop hook is used, and the applet can 4 
whatever it needs to do to stop its actions. 


public void destroy() { 


// applet is going away... 
} \ And the destroy hook is used when the applet 


is going to be destroyed, say, when the browser 
pane is closed. We could try to display 
something here, but what would be the point? 


Ne Well looky here! Our old friend the 
paint) method! Applet also makes 


use of this method as a hook. 


public void paint (Graphics g) { 
g.drawString(message, 5, 15); 
} 


Concrete applets make extensive use of hooks to supply their 
own behaviors. Because these methods are implemented as 
hooks, the applet isn’t required to implement them. 


youarehere > 307 


fireside chats: template method and strategy 


Fireside Chats 


== Tonight’s talk: Template Method and Strategy 
ae compare methods. 
Factory Method 
Template Method Strategy e 


Hey Strategy, what are you doing in my 
chapter? I figured [d get stuck with someone 
boring like Factory Method. 


I was just kidding! But seriously, what are you 
doing here? We haven't heard from you in eight 
chapters! 


You might want to remind the reader what 
you're all about, since it’s been so long. 


Hey, that does sound a lot like what I do. But 
my intent’s a little different from yours; my job 
is to define the outline of an algorithm, but 

let my subclasses do some of the work. That 
way, I can have different implementations of an 
algorithm’s individual steps, but keep control 
over the algorithm’s structure. Seems like you 
have to give up control of your algorithms. 
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Hey, I heard 
that! 


Nope, it’s me, although be careful — you and 
Factory Method are related, aren’t you? 


Td heard you were on the final draft of your 
chapter and I thought I'd swing by to see how 
it was going. We have a lot in common, so I 
thought I might be able to help... 


I don’t know, since Chapter 1, people have 
been stopping me in the street saying, “Aren’t 
you that pattern...” So I think they know who 
Iam. But for your sake: I define a family of 
algorithms and make them interchangeable. 
Since each algorithm is encapsulated, the client 
can use different algorithms easily. 


Tm not sure [’d put it quite like that... and 
anyway, [’m not stuck using inheritance for 
algorithm implementations. I offer clients a 
choice of algorithm implementation through 
object composition. 


Template Method 


I remember that. But I have more control over 
my algorithm and I don’t duplicate code. In fact, 
if every part of my algorithm is the same except 
for, say, one line, then my classes are much more 
efficient than yours. All my duplicated code 
gets put into the superclass, so all the subclasses 
can share it. 


Yeah, well, I’m real happy for ya, but don’t 
forget I’m the most used pattern around. 
Why? Because I provide a fundamental 
method for code reuse that allows subclasses to 
specify behavior. I’m sure you can see that this 
is perfect for creating frameworks. 


How’s that? My superclass is abstract. 


Like I said Strategy, ’'m real happy for you. 
Thanks for stopping by, but P’ve got to get the 
rest of this chapter done. 


Got it. Don’t call us, we'll call you... 


the template method pattern 


Strategy 


You might be a little more efficient (just a little) 
and require fewer objects. And you might also 
be a little less complicated in comparison to 
my delegation model, but I’m more flexible 
because I use object composition. With me, 
clients can change their algorithms at runtime 
simply by using a different strategy object. 
Come on, they didn’t choose me for Chapter | 
for nothing! 


Yeah, I guess... but, what about dependency? 
You’re way more dependent than me. 


But you have to depend on methods 
implemented in your superclass, which are part 
of your algorithm. I don’t depend on anyone; 
I can do the entire algorithm myself! 


Okay, okay, don’t get touchy. PIl let you 
work, but let me know if you need my special 
techniques anyway, ’'m always glad to help. 


crossword puzzle 


RS It’s that time again... 
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P| 


Across 
1. Strategy uses 
inheritance 
4. Type of sort used in Arrays 
5. The JFrame hook method that we overrode to 
print "| Rule" 
6. The Template Method Pattern uses 
to defer implementation to other 


rather than 


classes 

8. Coffee and 

9. Don't call us, we'll call you is known as the 
Principle 


12. A template method defines the steps of an 


13. In this chapter we gave you more 


14. The template method is usually defined in an method as a 


class 


16. Class that likes web pages 


Chapter 8 


Down 

2. algorithm steps are implemented 
by hook methods 

3. Factory Method is a of 


Template Method 
7. The steps in the algorithm that must be 
supplied by the subclasses are usually declared 


8. Huey, Louie and Dewey all weigh 


pounds 

9. A method in the abstract superclass that does 

nothing or provides default behavior is called a 
method 


10. Big headed pattern 


11. Our favorite coffee shop in Objectville 
15. The Arrays class implements its template 
method 


Tools for your Design Toolbox 


We’ve added Template Method to your toolbox. With 
Template Method you can reuse code like a pro while 
keeping control of your algorithms. 


00 Basies 


straction 


OO Princigles 


Encapsulate what varies: 
‘W 


apsulation 
lyreor phism 


: tance: 
alia er nner" 
sition ov evitance 


Favor comfo 


P gram te onterkacess not 
ro 


iyaplement ations 
ed designs 
for one cour’ sd 
ee ob jets Lat ter 
; en kor extension 


Classes oe os © Shiheation 


bade closed *° 


ptey DY not 
Jpstrractions 
Degend on 2 


derend on tontre classes: 
te 


only talk 2 YO friends 


Dont tall us We \ eall you 
on 


| And our newest pattern 
lets classes implementing, 
ee rremne a an algorithm d defer some 


steps to subclasses. 


’ \ 
as Tem? 

‘ pe skeleton a an algo fo subclasses 
al ‘ s ve deferring cage “a Se subclasses “€ 
5 a Template Men algrthe wither 

= tertain svers in he sbeueture- 


sharin Lhe algor 


BULLET as 


= A “template method” defines 


the template method pattern 


the steps of an algorithm, 
deferring to subclasses for the 
implementation of those steps. 


The Template Method 
Pattern gives us an important 
technique for code reuse. 


The template method’s 
abstract class may define 
concrete methods, abstract 
methods and hooks. 


Abstract methods are 
implemented by subclasses. 


Hooks are methods that do 
nothing or default behavior in 
the abstract class, but may be 
overridden in the subclass. 


To prevent subclasses from 
changing the algorithm in the 
template method, declare the 
template method as final. 


The Hollywood Principle guides 
us to put decision-making in 
high-level modules that can 
decide how and when to call 
low level modules. 


You'll see lots of uses of the 
Template Method Pattern in 
real world code, but don’t 
expect it all (like any pattern) to 
be designed “by the book.” 


The Strategy and Template 
Method Patterns both 
encapsulate algorithms, one 
by inheritance and one by 
composition. 


The Factory Method is a 
specialization of Template 
Method. 
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exercise solutions 


@qsharpen your pencil 
N Draw the new class diagram now that we’ve moved 
prepareRecipe() into the CaffeineBeverage class: 


Exereise 
solutions 


CaffeineBeverage 


prepareRecipe() 
boilWater() 
pourlnCup() 
brew() 
addCondiments() 


Coffee 


brew() 
addCondiments() 


brew() 
addCondiments() 


+9 


” 
WHS BDAES WHAT? 


Match each pattern with its description: 


Pattern Description 


Eneapsulate interchangable 
Template Methed behaviorsandusedelegationto 
decide which behavior to use 


Subclasses decide how 
© implement steps in an 
algorithm 


Strategy 


Factory Methed _ Subclasses decide which 


concrete classes to create 
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SEB Exercise solutions 
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9 the Iterator and Composite Patterns 


+ Well-Managed * 
Collections * 


You 
bet I keep my 
collections well 
encapsulated! 


There are lots of ways to stuff objects into a collection. Put them 
in an Array, a Stack, a List, a Hashtable, take your pick. Each has its own advantages and 
tradeoffs. But at some point your client is going to want to iterate over those objects, and 
when he does, are you going to show him your implementation? We certainly hope not! 
That just wouldn’t be professional. Well, you don’t have to risk your career; you’re going 

to see how you can allow your clients to iterate through your objects without ever getting 

a peek at how you store your objects. You’re also going to learn how to create some 
super collections of objects that can leap over some impressive data structures in a single 
bound. And if that’s not enough, you're also going to learn a thing or two about object 


responsibility. 
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big new: 


Breaking News: Objectville Diner and 
Objectville Pancake House Merge 


That’s great news! Now we can get those delicious pancake breakfasts at the 


Pancake House and those yummy lunches at the Diner all in one place. But, 
there seems to be a slight problem... 


... but we can't agree on 
how to implement our menus. 
That joker over there used an 
ArrayList to hold his menu items, and 
IT used an Array. Neither one of us is 
willing to change our implementations... 
we just have too much code written 
that depends on them. 


They want to use 
my Pancake House 
menu as the breakfast menu 
and the Diner's menu as the 
lunch menu. We've agreed on 
an implementation for the 
menu items... 


316 


the iterator and composite patterns 


Check out the Menu Items 
Objectville Dinos 


Vegetarian BLT 


At least Lou and Mel agree on the 
implementation of the Menultems. 
Let’s check out the items on each 
menu, and also take a look at the 
implementation. 


ts of lunch items, 


7 enu has lo 
The Diner men me gees 


while the Pancake 
breakfast items. Every menu item has a 
name, a description, and a price 


A hot dog, with 
I, Saurkra, 
topped with thee Regular Pancake Breakfast 


Pancakes With fried €995, Sausage = 


Blueberry Pancakes 


Pancakes made yj; 
le with ‘ 
and blueberry syrup "esh blueberries, 


Waffles 


Wattles, with your 
Or strawberries 


public class MenulItem { 3.59 
String name; 

String description; 
boolean vegetarian; 


double price; 


choice of blueberries 


public Menultem(String name, 
String description, 


boolean vegetarian, =; A 
Menultem é H 
onsists o 


double price) 


fa 
a flag to indicate if the re a destription, 


; vegetari 
this.name = name; and a price. You Pass all these val seat 
this.description = description; Constructor to initialize the M I a 

enu/tem. 


this.vegetarian = vegetarian; 
this.price = price; 


public String getName() { 
return name; 


These getter methods 


public String getDescription() { let you access the fields 
return description; of the menu item. 


public double getPrice() { 
return price; 


public boolean isVegetarian() { 
return vegetarian; 
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two menus 


Lou and Mel’s Menu implementations 


T used an ArrayList 
so I can easily 
expand my menu. 


Now let’s take a look at what Lou and Mel are 
arguing about. They both have lots of time and 
code invested in the way they store their menu 
items in a menu, and lots of other code that 
depends on it. 


Here’s Lou's implementation of the 
Pantake House menu- 


public class PancakeHouseMenu { 
ArrayList menultems; 


Lou's using an ArrayList to store 


public PancakeHouseMenu() { Cae ~ his menu items 


menultems = new ArrayList (); 


additem(“K&B’s Pancake Breakfast”, 
“Pancakes with scrambled eggs, and toast”, Each menu item is added to the 


2-38) AyrayList here, in the constructor 


2.99); a 


has a name, a 
addItem(“Regular Pancake Breakfast”, Each Menultem 


whether or not it's a 


“Pancakes with fried eggs, sausage”, description, : 
false, vegetarian item, and the price 
2,99)? 


additem(“Blueberry Pancakes”, 

“Pancakes made with fresh blueberries”, 
true, 

3.49); 


additem(“Waffles”, 
“Waffles, with your choice of blueberries or strawberries”, 


true, - 
. esa W 
3.59); ada mene item Lou ae arauments 
ad \t abject, passing in 63 List 
Menultem ; Lhe Preeay" 
public void addItem(String name, String description, and then adds * te 
boolean vegetarian, double price) -, 
{ 
MenuItem menuItem = new Menultem(name, description, vegetarian, price); 
menultems.add(menultem) ; ; of iL 
} The getMenultems() method returns the list of menu items 


public ArrayList getMenuItems() { 
a eee Lou has a bunch of 
<—_ the ArrayList implementation. 
have to rewrite all that todel 


other menu Code that depends on 
He doesn’t want to 


// other menu methods here 


} 
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Haah! An Arraylist... I 
used a REAL Array so I can 
control the maximum size of my menu 
and get my MenuItems without 
having to use a cast. 


- of the Diner menu 
1, Mel's implementation ° 
oe And here's Me 
wipe ce he 

public class DinerMenu { Mel takes a different approach; hes using an ie “2 : 

static final int MAX ITEMS = 6; tan control the max size of the menu and retrieve men 

Tae aes ema ie —— items out without having to cast his objects. 

Menultem[] menultems; 


public DinerMenu() { Like Lou, Mel creates his menu items in the 
Bie agree x Te an ee Oe rae wo consteuttor, using the additem() helper method. 


addiItem(“Vegetarian BLT”, 
“(Fakin’) Bacon with lettuce & tomato on whole wheat”, true, 2.99); 
addItem(“BLT”, 
“Bacon with lettuce & tomato on whole wheat”, false, 2.99); 
addItem(“Soup of the day”, 
“Soup of the day, with a side of potato salad”, false, 3.29); 
addItem(“Hotdog”, 
“A hot dog, with saurkraut, relish, onions, topped with cheese”, 
false, 3.05); 
// a couple of other Diner Menu items added her 


addltem() takes all the parameters 


i necessary to create a Merultem and : 
i i cheeks to make 
public void addItem(String name, String description, sastantiates one- i leg 


) : r h it. 
boolean vegetarian, double price) sure we haven't hit the menu size lim 


MenulItem menuItem = new Menultem(name, description, vegetarian, ne 
if (numberOfItems >= MAX ITEMS) { 


System.err.printlin(“Sorry, menu is full! Can’t add item to menu”); 
} else { 
under a 


el specifi i 
Facies eae se th = eee: M ra aioe wants to keep his mene 
Sa ee ce ee certain size Presumably so he doesn't have to 
remember too many recipes). 


public MenuItem[] getM ile ons «Nel bead returns the array of menu items. 


return menultems; 


} 
Like Lou, Mel has a bunch of code that depends on the implementation of 
// other menu methods here <—— his menu being an Array. He’s too busy ¢ooking to rewrite all of this. 
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java enabled waitress 


What’s the problem with having two different 
menu representations? 


To see why having two different menu representations complicates 


The Waitress 'S abied- 
things, let’s try implementing a client that uses the two menus. 
Imagine you have been hired by the new company formed by the 


. va-en 
( o¢ nd Ja 

merger of the Diner and the Pancake House to create a Java-enabled 

waitress (this zs Objectville, after all). The spec for the Java-enabled 

waitress specifies that she can print a custom menu for customers on 


demand, and even tell you if a menu item is vegetarian without having 
to ask the cook — now that’s an innovation! 


Let’s check out the spec, and then step through what it might take to 
implement her... 


The Java-Enabled Waitress Specification 


- e “Alice” 
Java-Enabled Waitress: code-nam 


intMenu () - 
ere every item on the me 


Q) 
sntBreakfastMenu , 
sage just preakfast items 


i tLunchMenu () . 
~e prints just Junch items 


; etarianMenu() | eats 
caeeee lee all vegetarian menu ite 
sem 


,an (name) ae 
ae name of an item, a 
: ees items is vegetarian, otherwise, 
if e 


GK The spee for 
the Waitress 


returns false 
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Let’s start by stepping through how we’d implement the printMenu() method: 


1) To print all the items on each menu, you'll need to call the getMenultems() 
method on the PancakeHouseMenu and the DinerMenu to retrieve their 


: : . looks 
respective menu items. Note that each returns a different type: The method 


the same, but the 
talls ave returning 
different types: 


PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; 
ArrayList breakfastItems = pancakeHouseMenu.getMenulItems () ; 


DinerMenu dinerMenu = new DinerMenu() ; Theil : 
MenulItem[] lunchItems = dinerMenu.getMenulItems () ; . 7 a ementation 
is showing through, 


breakfast items are 
in an ArrayList, lunch 
items are in an Array. 


2] Now, to print out the items from the PancakeHouseMenu, we'll loop through the 
items on the breakfastItems ArrayList. And to print out the Diner items we'll 


loop through the Array. Now, we have to 
6 implement two different 

for (int i = 0; i < breakfastItems.size(); i++) { loops to step through the 
Menultem menultem = (MenulItem) breakfastItems.get (i); rn implementations 
System.out.print (menultem.getName() + “ ”); Dw apni items... 
System.out.printin(menultem.getPrice() + “ ”); 
System.out.printlin(menultem.getDescription()); 

} ..one loop for the 

for (int i = 0; i < lunchItems.length; i++) { ArrayList... 
MenulItem menultem = lunchItems [i]; shed another foe 
System.out.print (menultem.getName() + “ ”); = ane eee 
System.out.printlin(menuItem.getPrice() + “ "); Y: 
System.out.printlin(menultem.getDescription()); 


Ss) Implementing every other method in the Waitress is going to be a variation of 
this theme. We’re always going to need to get both menus and use two loops to 
iterate through their items. If another restaurant with a different implementation 
is acquired then we'll have three loops. 


youarehere > 321 


what’s the goal 


G harpen our pencil 
\ y 


Based on our implementation of printMenu(), which of the following apply? 


LJ A. We are coding to the LJ D. The Waitress needs to know how each 
PancakeHouseMenu and DinerMenu menu represents its internal collection of 
concrete implementations, not to an menu items; this violates encapsulation. 


nae . We have duplicate code: the printMenu() 


LJ B. The Waitress doesn’t implement the method needs two separate loops to 
Java Waitress API and so she isn’t iterate over the two different kinds of 
adhering to a standard. menus. And if we added a third menu, 
we'd have yet another loop. 


LI C. If we decided to switch from using 
DinerMenu to another type of menu . The implementation isn’t based on 
that implemented its list of menu items MXML (Menu XML) and so isn’t as 
with a Hashtable, we’d have to modify interoperable as it should be. 

a lot of code in the Waitress. 


What now? 


Mel and Lou are putting us in a difficult position. They don’t want to change their 
implementations because it would mean rewriting a lot of code that is in each respective menu 
class. But if one of them doesn’t give in, then we’re going to have the job of implementing a 
Waitress that is going to be hard to maintain and extend. 


It would really be nice if we could find a way to allow them to implement the same interface for 
their menus (they’re already close, except for the return type of the getMenultems() method). 
That way we can minimize the concrete references in the Waitress code and also hopefully get 
rid of the multiple loops required to iterate over both menus. 


Sound good? Well, how are we going to do that? 


the iterator and composite patterns 
Can we encapsulate the iteration? 


If we’ve learned one thing in this book, it’s encapsulate what varies. It’s obvious 
what is changing here: the iteration caused by different collections of objects 
being returned from the menus. But can we encapsulate this? Let’s work 
through the idea... 


© To iterate through the breakfast items we use the size() and get() 
methods on the ArrayList: 


for (int i = 0; i < breakfastItems.size(); i++) { 
MenuItem menuItem = (MenuItem) breakfastItems.get (i) ; 
as: 


} 
get(1) get(2) get(3) * get helps us step 
get(0) y \ Lhrough each item 
. ArrayList 


ES An ArrayList 
of Menultems 


Henare® | Menurxe® | Yenurre® || Menatxe™ 
1 2 3) 4 


© And to iterate through the lunch items we use the Array length field and 
the array subscript notation on the MenuItem Array. 


lunchitems[0] 


for (int i = 0; i < lunchItems.length; al a ee 
MenuItem menuItem = lunchItems [i] ; —_tachitems(1) 
} 
Altemsr2 
hig 
We use the array &ms[3 


subseripts to step eo 


through items. 
An Array of _ 7 
Menultems. 


J 


fe) 
4 
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we 


encapsulating iteration 


3 ] Now what if we create an object, let's call it an Iterator, 
that encapsulates the way we iterate through a We ask the breakfastMenu 
collection of objects? Let's try this on the ArrayList 


for an iterator of its 
—_ Menultems. 


Iterator iterator = breakfastMenu.createIterator () ; 


find while there ave m items left... 
while (iterator.hasNext()) { =" ee 


MenuItem menuitem = (MenuItem) iterator.next() ; 


N 
next() We get the next item. 


a 
get(2) 
rr Trevor Ss \ oo) 


get(1) 


ArrayList y 
The client just calls hasNext() and evn a. 


nextQ; behind the scenes the iterator 
calls get() on the ArrayList. O 
Menire® | Yenire® | Yenurre® | Menarxe™ 


1 2 3 4 


© Let's try that on the Array too: 


Iterator iterator = lunchMenu.createIterator () ; 


while (iterator.hasNext()) { 


MenuItem menuItem = (MenuItem) iterator.next() ; 
_ 
Wow, this code next() 
is exactly the 
enn ra lunchitems[0] 


“breakfastMenu 


lu 
Same situation here: the client just calls tera Schitemsro) 
hasNext() and next(); behind the scenes, unch 
the iterator indexes into the Array. Hemsr3, 
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Meet the Iterator Pattern 


Well, it looks like our plan of encapsulating iteration just might 
actually work; and as you’ve probably already guessed, it is a 
Design Pattern called the Iterator Pattern. 


The first thing you need to know about the Iterator Pattern is 
that it relies on an interface called Iterator. Here’s one possible 
Iterator interface: 

The hasNext() method 

tells us if there are 

more elements in the 


<<interface>> aggregate to iterate 
Iterator throu gh- 
hasNext() 


next() 
aa The next() method 


returns the next object 
in the aggregate. 


Now, once we have this interface, we can implement Iterators for 
any kind of collection of objects: arrays, lists, hashtables, .. pick 
your favorite collection of objects. Let’s say we wanted to 
implement the Iterator for the Array used in the DinerMenu. It 
would look like this: 


When we say 
COLLECTION we just 
mean a group of objects. They 
might be stored in very different 
data structures like lists, arrays, 
hashtables, but they're 
still collections. We also 
sometimes call these 
AGGREGATES. 


<<interface>> 
Iterator 


hasNext() 
next() 


re DinerMenulterator is an 
implementation of |terator 
that knows how to iterate 
over an arvay of Menultems. 


DinerMenulterator 


hasNext() 
next() 


Let’s go ahead and implement this Iterator and hook it into the 
DinerMenu to see how this works... 
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make an iterator 


Adding an Iterator to DinerMenu 


To add an Iterator to the DinerMenu we first need to define the 
Iterator Interface: 


Here’s our two methods: 


The hasNext() method returns a boolean 
indicating whether or not there are more 


public interface Iterator { J Accent Lo iterate over... 


boolean hasNext (); 


Object next (); 
; oe oe 


--and the nextQ) method 
returns the next element. 


And now we need to implement a concrete Iterator that works 


for the Diner menu: We implement the 


aa |terator interface. 


public class DinerMenulIterator implements Iterator { re maintains the 
\ 
Menultem[] items; ye Lo of the 
int position = 0; rr current saa array: 
iteration over me 


public DinerMenulIterator(MenuItem[] items) { 


this.items = items; RO The constructor takes the 
} array of menu items we are 
public Object next() { sens eae ae 
MenulItem menultem = items[position]; The nextl) method returns the 


position = position + 1; . . 
sees ieee ae next item in the array and 


} inerements the position. 


public boolean hasNext() { 
if (position >= items.length || items[position] == null) { 
return false; 


} else f{ 
return true; ‘) 
} 


} Because the diner chef went ahead and 
} The hasNext() method cheeks to allocated a max sized array, we need to 
see if we've seen all the elements check not only if we ave at the end of 
of the array and returns true if the array, but also if the next item is 
there ave more to iterate through. null, which indicates there are no more 
items. 
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Reworking the Diner Menu with Iterator 


Okay, we’ve got the iterator. Time to work it into the 
DinerMenu; all we need to do is add one method to create a 
DinerMenulterator and return it to the client: 


public class DinerMenu { 
static final int MAX ITEMS = 6; 
int numberOfItems = 0; 
Menultem[] menuItems; 


// constructor here 
We're not going to need the getMenultems() 
a method anymore and in fact, we don't want it 


because it exposes our internal implementation! 


// addItem here 


| aan a Ean EEE LAL RAC 
ie 
public Iterator createIterator() { 
return new DinerMenuIterator (menultems) ; Here’s the ereatelterator() method. 
} It ereates a DinerMenulterator 
from the menultems array and 
// other menu methods here veluvoeil do thewlent: 


We've returning the |terator interface. The ¢lient 

doesn’t need to know how the menultems are maintained 

in the DinerMenu, nor does it need to know how the 
DinerMenulterator is implemented. It just needs to use the 
iterators to step through the items in the menu. 


A 
Exercise 


Go ahead and implement the PancakeHouselterator yourself and make the changes 
needed to incorporate it into the PancakeHouseMenu. 
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Fixing up the Waitress code 


Now we need to integrate the iterator code 
into the Waitress. We should be able to get 
rid of some of the redundancy in the process. 
Integration is pretty straightforward: first we 


create a printMenu() method that takes an yr 
Iterator, then we use the createlterator() method New and improved gy 
on each menu to retrieve the Iterator and pass it with [terator. 


to the new method. 


Se 8 hee { A In the constructor the Waitress 
sree rie al (wate nn 
public Waitress (PancakeHouseMenu pancakeHouseMenu, DinerMenu dinerMenu) { 
this.pancakeHouseMenu = pancakeHouseMenu; The print Menv() 
this.dinerMenu = dinerMenu; method now 
} ereates two 
iterators, one vor 
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public void printMenu() { 
Iterator pancakelIterator = pancakeHouseMenu.createlIterator(); 
Iterator dinerIterator = dinerMenu.createlIterator (); a 
And then talls the 
<= __ overloaded printMenul) 
1 with each iterator. 


each menu: 


System. out.println (“MENU\n----\nBREAKFAST”) ; 
printMenu (pancakelIterator) ; 

System.out.println(“\nLUNCH”) ; 
printMenu (dinerIterator) ; Test if there are 


ailens The overloaded 
any mo! mn 


printMenul) 
private void printMenu(Iterator iterator) — Get the method uses the 
while (iterator.hasNext()) { next item. Iterator to step 
Menultem menuItem = (Menultem)iterator.next (); through the menu 
System.out.print (menultem.g tNam (i se NS My hace and print 
System.out.print (menultem.getPrice() + “ -- “); 
System.out.printlin(menultem.getDescription()); them. 
} Use the item to 
Note that we're down get name, price 
// other methods here to one loop. and description 
—— and print them. 
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Testing our code 


It’s time to put everything to a test. Let’s write some 
test drive code and see how the Waitress works... 


First we create the new menus. 


public class MenuTestDrive { a 
public static void main(String args[]) { 
PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; 
DinerMenu dinerMenu = new DinerMenu() ; 


Waitress waitress = new Waitress (pancakeHouseMenu, dinerMenu) ; —& Then we ¢reate a 
Waitress and pass her 


waitress.printMenu () ; the menus. 


} Then we print them. 


Here’s the test run... 


File Edit Window Help GreenEggs&Ham 


2 


% java DinerMenuTestDrive First we iterate 


MENU through the pancake 
———— CC menu. 
BREAKFAST And then 


K&B’s Pancake Breakfast, 2.99 -- Pancakes with scrambled eggs, and toast the lunch 
Regular Pancake Breakfast, 2.99 -- Pancakes with fried eggs, sausage menu, all 
Blueberry Pancakes, 3.49 -- Pancakes made with fresh blueberries withethe 
Waffles, 3.59 -- Waffles, with your choice of blueberries or strawberries 


Same 
LUNCH tie iteration 


Vegetarian BLT, 2.99 -- (Fakin’) Bacon with lettuce & tomato on whole wheat ode. 
BLT, 2.99 -- Bacon with lettuce & tomato on whole wheat 

Soup of the day, 3.29 -- Soup of the day, with a side of potato salad 

Hotdog, 3.05 -- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice, 3.99 -- Steamed vegetables over brown rice 

Pasta, 3.89 -- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


% 
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iterator advantages 


Woohoo! No 
code changes other 
than adding the 
createIterator() method. 


What have we done so far? 


For starters, we’ve made our Objectville cooks 
very happy. They settled their differences and 
kept their own implementations. Once we 

gave them a Pancake HouseMenulterator and a 
DinerMenulterator, all they had to do was add a 
createIterator() method and they were finished. 


We've also helped ourselves in the process. The 
Waitress will be much easier to maintain and 

extend down the road. Let’s go through exactly 
what we did and think about the consequences: 


Hard to Maintain New, Hip 
Waitress Implementation Waitress Powered by Iterator 


The Menus are not well 
encapsulated; we can see the 
Diner is using an ArrayList and the 
Pancake House an Array. 


The Menu implementations are now 
encapsulated. The Waitress has 
no idea how the Menus hold their 
collection of menu items. 


We need two loops to iterate through 
the Menultems. 


All we need is a loop that 
polymorphically handles any 
collection of items as long as it 
implements Iterator. 


The Waitress is bound to concrete The Waitress now uses an interface 
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classes (Menultem[] and ArrayList). 


The Waitress is bound to two different 
concrete Menu classes, despite their 
interfaces being almost identical. 


apter 7 


(Iterator). 


The Menu interfaces are now exactly 
the same and, uh oh, we still don’t 
have a common interface, which 
means the Waitress is still bound to 
two concrete Menu classes. We'd 
better fix that. 


the iterator and composite patterns 


What we have so far... 


Before we clean things up, let’s get a bird’s eye view of our current design. 


se two menus implement the 
bie exact set of methods, but 
they arent implementing . - 
Interface. We're going to fix thi 
and free the Waitress from any 
dependencies on tonerete Menus: 


\ 


PancakeHouseMenu 


menultems 


createlterator() 


DinerMenu 


menultems 


createlterator() 


Note that the iterator give us a way to 


the elements of an aggregate without foreing the 
aggregate to clutter its own interface wi 


The Iterator allows the Waitress to be decoupled from We re now 

the actual implementation of the contrete classes. She lhe a Common 
doesn't need to know if a Menu is implemented with ! erator 

an Array, an ArrayList, or with Postlt notes. All shir 

she caves is that she can get an Iterator to do her a weve 
iterating, implemented 


wo Concrete 


JN Sf 


Waitress <<interface>> 
printMenu() Iterator 
hasNext() 
next() 


DinerMenulterator 


hasNext() 
next() 


PancakeHouseMenulterator 


hasNext() 
next() 


\ n implement 


PancakettouseMenu and DinerMen 


() method; they ave 
the new ents the iterator te their 


step through 


responsible for ¢ 


th a bunch 


: vkems im mentations- 
methods to support traversal of its elemen reat vespective menu items imple 
also allows the implementation of the iterator to 


live outside of the aggregate; i 
encapsulated the interation. 


In other words, weve 
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Making some improvements... 


Okay, we know the interfaces of PancakeHouseMenu and DinerMenu are exactly the same 
and yet we haven’t defined a common interface for them. So, we’re going to do that and 
clean up the Waitress a little more. 


You may be wondering why we’re not using the Java Iterator interface — we did that so you 
could see how to build an iterator from scratch. Now that we’ve done that, we’re going to 
switch to using the Java Iterator interface, because we'll get a lot of leverage by implementing 
that instead of our home grown Iterator interface. What kind of leverage? You'll soon see. 


First, let’s check out the java.util.Iterator interface: 


4» This looks just like ou previous definition. 


<<interface>> 
Iterator 


hasNext() 
next() 
remove() 


Exeept we have an additional method that 
allows us to remove the last item returned by 
the next) method from the aggregate. 


This is going to be a piece of cake: We just need to change the interface that both 

Pancake HouseMenulterator and DinerMenulterator extend, right? Almost... actually, it’s 
even easier than that. Not only does java.util have its own Iterator interface, but ArrayList has 
an iterator() method that returns an iterator. In other words, we never needed to implement 
our own iterator for ArrayList. However, we'll still need our implementation for the 
DinerMenu because it relies on an Array, which doesn’t support the iterator() method (or any 
other way to create an array iterator). 


thereyareno sg 
Dumb Questions 
+ What if | don’t want to provide : 
the ability to remove something from the 
underlying collection of objects? 


How does remove() behave 
under multiple threads that may be 
using different iterators over the same 
collection of objects? 


the runtime exception 
java.lang.UnsupportedOperationException. 
The Iterator API documentation specifies that 


A: The remove() method is considered 
optional. You don’t have to provide remove 
functionality. But, obviously you do need to 


A: The behavior of the remove() is 
unspecified if the collection changes while 


provide the method because it’s part of the 
Iterator interface. If you're not going to allow 
remove() in your iterator you'll want to throw 
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this exception may be thrown from remove() 
and any client that is a good citizen will 
check for this exception when calling the 
remove() method. 


you are iterating over it. So you should be 
careful in designing your own multithreaded 
code when accessing a collection 
concurrently. 


the iterator and composite patterns 


Cleaning things up with java.util. terator 


Let’s start with the PancakeHouseMenu, changing it over to java.util.Iterator is 
going to be easy. We just delete the PancakeHouseMenulterator class, add an 


import java.util.Iterator to the top of PancakeHouseMenu and change one line 
of the PancakeHouseMenu: 


Sie puede eeeaeeeearssegi 4 en Instead of creating our own iterator 
return menultems.iterator (); now, we just call the iterator() method 
on the menultems ArrayList. 


And that’s it, Pancake House Menu 1s done. 


Now we need to make the changes to allow the DinerMenu to work with java.util. Iterator. 


ee First we import javautil.terator, the 


interface we've going to implement. 


import java.util.Iterator; 


public class DinerMenulIterator implements Iterator { 
MenulItem[] list; 


int position = 0; 


public DinerMenulIterator(MenuItem[] list) 
this.list = list; 


{ 


None of our current 


implementation changes--- 
public Object next() { 
//implementation here 


but we do need to implement removel). 
Here, because the chef is using a fixed 

segs © cue hae anae as sized Array, we just shift all the 

} fee elements up one when removel() is called. 


public void remove() { 
if (position <= 0) { 
throw new IllegalStateException 
(“You can’t remove an item until you’ve done at least one next()”); 


} 


it (Ligiel@osuicuem—1)| $= mull) { 
for (ime 2 = pOSsLEn@a-lp a < (ilisie. legit) aasr)) 4 
Aasie [a ]) = Mase ala ¢ 


} 
list[list.length-1] = null; 
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decouple the waitress from the menus 


We are almost there... 


We just need to give the Menus a common interface and rework the Waitress 

a little. The Menu interface is quite simple: we might want to add a few more 
methods to it eventually, like addItem(), but for now we will let the chefs control 
their menus by keeping that method out of the public interface: 


This is a simple interface that just 
— lets clients get an iterator fon 
the items in the menu. 


public interface Menu { 
public Iterator createIterator(); 


Now we need to add an implements Menu to both the 
PancakeHouseMenu and the DinerMenu class definitions and 
update the Waitress: 


ze ON Now the Waitress uses the java.util-terator as well. 


import java.util.Iterator; 


public class Waitress { 
Menu pancakeHouseMenu; We need to replace the 
Menu dinerMenu; concrete Menu classes 
with the Menu Interface. 
public Waitress (Menu pancakeHouseMenu, Menu dinerMenu) { 


this.pancakeHouseMenu = pancakeHouseMenu; 
this.dinerMenu = dinerMenu; 


public void printMenu() { 
Iterator pancakelIterator = pancakeHouseMenu.createlIterator (); 
Iterator dinerIterator = dinerMenu.createlIterator(); 


System.out.println (“MENU\n----\nBREAKFAST”) ; 
printMenu (pancakelIterator) ; Nothing changes 
System.out.println(“\nLUNCH”) ; hee 3 


printMenu (dinerIterator) ; 


private void printMenu(Iterator iterator) { 


while (iterator.hasNext()) { 
Menultem menuItem = (MenulItem) iterator.next(); 
System.out.print (menuItem.getName() + “, “); 
System.out.print (menuItem.getPrice() + “ -- “); 
System.out.printlin (menultem.getDescription()); 


// other methods here 
} 
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What does this get us? 


The PancakeHouseMenu and DinerMenu classes implement an interface, 
Menu. Waitress can refer to each menu object using the interface rather than 
the concrete class. So, we’re reducing the dependency between the Waitress and 
the concrete classes by “programming to an interface, not an implementation.” 


The new Menu interface has one method, createlterator(), that is implemented 
by PancakeHouseMenu and DinerMenu. Each menu class assumes the 


responsibility of creating a concrete Iterator that is appropriate for its internal 
implementation of the menu items. 


Ly 


Now, Waitress 


We ve decouP? 


This solves the problem of 
Lhe Waitress depending on 
the contrete Menus. 


This solves the problem of 
the Waitress depending on 


the implementation of the 
Menultems. 


led Waitress Lerom the 


, so now 
only needs to 7 mplementation of He i eae 
) terator ’ 
Here’s our new Menu interface. ane’ 4 we can “ : ; menu ibems without 
It specifies the new method, al a over any "iS ° ne the list 
createlterator(). Iterators. having, te Know 3 Lea 
of items is implemen ; 
<<interface>> Waitress <<interface>> 
Menu printMenu() Iterator 
createlterator() hasNext() 
next() 
remove() 


PancakeHouseMenu DinerMenu 


PancakeHouseMenulterator DinerMenulterator 


menultems menultems 


hasNext() 
next() 


hasNext() 
next() 
remove() 


createlterator() createlterator() 


remove() 


¢ PaneakeHtouseMenu and 
the Menu interface, 
implement the new ¢ 


\ 


Each conerete Menu is responsible 
for creating the appropriate 
conerete Iterator class. 


DinerMenu returns 

an DinerMenulterator 
from its 
treatelterator( 
method because that’s 
the kind of iterator 
required to iterate 
over its Array of 


menu items. 


DinerMenu now implement 
which means they need to 


reatelterator() method. We've now using the ArrayList 


iterator supplied by java.util. 
We don’t need this anymore. 


> 
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Iterator Pattern defined 


You've already seen how to implement the Iterator 
Pattern with your very own iterator. You’ve also seen 
how Java supports iterators in some of its collection 
oriented classes (the ArrayList). Now it’s time to check 
out the official definition of the pattern: 


The Iterator Pattern provides a way to 
access the elements of an aggregate object 


sequentially without exposing its underlying 
representation. 


This makes a lot of sense: the pattern gives you a way 
to step through the elements of an aggregate without 
having to know how things are represented under the 
covers. You’ve seen that with the two implementations 
of Menus. But the effect of using iterators in your 
design is just as important: once you have a uniform way 
of accessing the elements of all your aggregate objects, 
you can write polymorphic code that works with any 

of these aggregates — just like the printMenu() method, 
which doesn’t care if the menu items are held in an 
Array or ArrayList (or anything else that can create an 
Iterator), as long as it can get hold of an Iterator. 


The other important impact on your design is that the 
Iterator Pattern takes the responsibility of traversing 
elements and gives that responsibility to the iterator 
object, not the aggregate object. This not only keeps 
the aggregate interface and implementation simpler, 

it removes the responsibility for iteration from the 
ageregate and keeps the aggregate focused on the 
things it should be focused on (managing a collection of 
objects), not on iteration. 


Let’s check out the class diagram to put all the pieces in 
context... 
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The Iterator Pattern allows 
traversal of the elements 

of an aggregate without 
exposing the underlying 


implementation. 


It also places the task of 
traversal on the iterator 
object, not on the aggregate, 
which simpli@es the 
ageregate interface and 
implementation, and places 


the responsibility where it 
should he. 


the iterator and composite patterns 


| The Iterator interface 
Having a Common interface for Your provides the interface 
aggregates is handy for a lient; 


, that all iterators 
it decouples your client from the must implement ms 
implementation of Your collection of objects. 


a set of methods 
<<interface>> 
Aggregate 


for traversing over 
createlterator() 


Client <<interface>> elements of a Collection. 
Iterator : 
Here we're using the 
hasNext() 


iava-util.[terator. If you 
next() J ° 
remove() don’t want to use Java's 
Iterator interface, you 
can always Create your 


own: 


ConcreteAggregate Concretelterator 
createlterator() hasNext() 
next() 
0 Be Each ContreteAggregate lite, 


is vesponsible for 


instantiating a 
The ContreteAggregate Coneretelterator that 7) \ 
has a Collection of can iterate over its The Coneretelterator is 
objects and implements tolleetion of objects. responsible for managing, 
the method that the current position of 
returns an Iterator for the iteration. 
its Collection. 


ge RALN 
POWER 


The class diagram for the Iterator Pattern looks very similar to another Pattern you’ve studied; can you 
think of what it is? Hint: A subclass decides which object to create. 
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q&a about ite 


Q: I’ve seen other books show the 
Iterator class diagram with the methods 
first(), next(), isDone() and currentltem(). 
Why are these methods different? 


A: Those are the “classic” method 
names that have been used. These names 
have changed over time and we now have 
next(), hasNext() and even remove() in 
java.util. Iterator. 


Let’s look at the classic methods. The 
next() and currentltem() have been merged 
into one method in java.util. The isDone() 
method has obviously become hasNext(); 
but we have no method corresponding to 
first(). That’s because in Java we tend to 
just get a new iterator whenever we need to 
start the traversal over. Nevertheless, you 
can see there is very little difference in these 
interfaces. In fact, there is a whole range 
of behaviors you can give your iterators. 
The remove() method is an example of an 
extension in java.util. Iterator. 


Q: I’ve heard about “internal” 
iterators and “external” iterators. What 
are they? Which kind did we implement 
in the example? 


A: We implemented an external iterator, 
which means that the client controls the 
iteration by calling next() to get the next 
element. An internal iterator is controlled 

by the iterator itself. In that case, because 
it’s the iterator that’s stepping through the 
elements, you have to tell the iterator what 
to do with those elements as it goes through 
them. That means you need a way to pass 
an operation to an iterator. Internal iterators 
are less flexible that external iterators 
because the client doesn’t have control of 
the iteration. However, some might argue 
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thereyareno sg 
pum Questions 
that they are easier to use because you just 


hand them an operation and tell them to 
iterate, and they do all the work for you. 


* Could! implement an Iterator that 
can go backwards as well as forwards? 


A: Definitely. In that case, you'd 
probably want to add two methods, one to 
get to the previous element, and one to tell 
you when you're at the beginning of the 
collection of elements. Java's Collection 
Framework provides another type of iterator 
interface called Listlterator. This iterator 
adds previous() and a few other methods 

to the standard Iterator interface. It is 
supported by any Collection that implements 
the List interface. 


+ Who defines the ordering of the 
iteration in a collection like Hashtable, 
which are inherently unordered? 


A: Iterators imply no ordering. The 
underlying collections may be unordered as 


in a hashtable or in a bag; they may even 
contain duplicates. So ordering is related 
to both the properties of the underlying 
collection and to the implementation. In 
general, you should make no assumptions 
about ordering unless the Collection 
documentation indicates otherwise. 


: You said we can write 
“polymorphic code” using an iterator; 
can you explain that more? 


A: When we write methods that take 
Iterators as parameters, we are using 
polymorphic iteration. That means we are 
creating code that can iterate over any 


collection as long as it supports Iterator. 
We don’t care about how the collection 
is implemented, we can still write code to 
iterate over it. 


Q: If ’'m using Java, won’t | always 
want to use the java.util. Iterator 
interface so | can use my own iterator 
implementations with classes that are 
already using the Java iterators? 


A: Probably. If you have a common 
Iterator interface, it will certainly make it 
easier for you to mix and match your own 
aggregates with Java aggregates like 
ArrayList and Vector. But remember, if you 
need to add functionality to your Iterator 
interface for your aggregates, you can 
always extend the Iterator interface. 


Q: I’ve seen an Enumeration 
interface in Java; does that implement 
the Iterator Pattern? 


A: We talked about this in the Adapter 
Chapter. Remember? The java.util. 
Enumeration is an older implementation 

of Iterator that has since been replaced 

by java.util Iterator. Enumeration has 

two methods, hasMoreElements(), 
corresponding to hasNext(), and 
nextElement(), corresponding to next(). 
However, you'll probably want to use Iterator 
over Enumeration as more Java classes 
support it. If you need to convert from one 
to another, review the Adapter Chapter 
again where you implemented the adapter 
for Enumeration and Iterator. 


Single Responsibility 


What if we allowed our aggregates to 
implement their internal collections and 
related operations AND the iteration 
methods? Well, we already know that 
would expand the number of methods in 
the aggregate, but so what? Why is that 
so bad? 


Well, to see why, you first need to recognize that when we allow 
a class to not only take care of its own business (managing 
some kind of aggregate) but also take on more responsibilities 
(like iteration) then we’ve given the class two reasons to change. 
Two? Yup, two: it can change if the collection changes in 
some way, and it can change if the way we iterate changes. So 
once again our friend CHANGE is at the center of another 
design principle: 


Design Principle 


A class should have only one 
reason to change. 


We know we want to avoid change in a class like the plague 
~ modifying code provides all sorts of opportunities for 
problems to creep in. Having two ways to change increases 
the probability the class will change in the future, and when 
it does, it’s going to affect two aspects of your design. 


The solution? The principle guides us to assign each 
responsibility to one class, and only one class. 


That’s right, it’s as easy as that, and then again it’s not: 
separating responsibility in design is one of the most 
difficult things to do. Our brains are just too good at seeing 
a set of behaviors and grouping them together even when 
there are actually two or more responsibilities. The only 
way to succeed is to be diligent in examining your designs 
and to watch out for signals that a class is changing in more 
than one way as your system grows. 


the iterator and composite patterns 


Every responsibility ofa 
class is an area of potential 
change. More than one 
responsibility means more 
than one area of change. 


This principle guides us to 
keep each class to a single 


responsibility. 


a Cohesion is a term you'll 
\ hear used as a measure of 


\ how closely a class or a 
| 3 module supports a single 


| 
o purpose or responsibility. 


We say that a module or 
class has high cohesion 
when it is designed around a set of 
related functions, and we say it has low 
cohesion when it is designed around a 
set of unrelated functions. 


Cohesion is a more general concept 
than the Single Responsibility Principle, 
but the two are closely related. 

Classes that adhere to the principle 
tend to have high cohesion and are 
more maintainable than classes that 
take on multiple responsibilities and 
have low cohesion. 
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multiple responsibilities 


WALI 


RELA 


Examine these classes and determine which ones have multiple responsibilities. 


GumballMachine 


Person 


tCount 
setName() avon) 


tAddress() getState() 

setAddress| 

login() dial() getLocation() 
setPhoneNumber() 

signup() 


move() 


save() hangUp() 


load() talk() 
fire() sendData() 


rest() flash() 


Iterator 


DeckOfCards hasNext) 
hasNext() ShoppingCart 
next() add() 
remove() remove() 
addCard() checkOut() 
removeCard() saveForLater() 


shuffle() 


next() 
remove() 


' 


HARD HAT AREA, WATCH OUT 
FOR FALLING ASSUMPTIONS 


Determine if these classes have low or high cohesion. 


PlayerActions 


login() ; move() Player 

GameSession 
signup() ical fire() getHighScore() 
move() ogin() rest() 


fre) signup() 


rest() 


getName() 


getHighScore() 


getName() 
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Good thing you're learning 
about the Iterator pattern 
because I just heard that Objectville 
Mergers and Acquisitions has done 
another deal... we're merging with 
Objectville Café and adopting their 
dinner menu. 


Wow, and we thought things 
were already complicated. 
Now what are we going to do? 


think positively, I'm 
sure we can find a way to 


the iterator and composite patterns 


Come on, 


work them into the 
Iterator Pattern. 


anew menu 


Taking a look at the Café Menu 


Here’s the Café Menu. It doesn’t look like too much trouble to integrate the 
Cafe Menu into our framework... let’s check it out. 
implement our new 


fixed 


Menu 
CafeMenu doesn + 


as is easil 
interfate, bok NES : The Café is storing their menu items in Hashtable. 


Vj 
public class CafeMenu { Does that support Iterator? We'll see shortly... 
Hashtable menultems = new Hashtable(); SS 


Like the other Menus, the menu items are 
public CafeMenu() { 


LC. initialized in the constructor. 
addItem(“Veggie Burger and Air Fries”, 


“Veggie burger on a whole wheat bun, lettuce, tomato, and fries”, 
true, 3.99); 

addiItem(“Soup of the day”, 

“A cup of the soup of the day, with a side salad”, 

false, 3.69); 

addiItem(“Burrito”, 

“A large burrito, with whole pinto beans, salsa, guacamole”, 
true, 4.29); 


Here’s where we Create a new eatin 
i hashtable. 
public void addItem(String name, String description, and add it to the cmoalbene ha 
boolean vegetarian, double price) 


{ 


MenuItem menuItem = new Menultem(name, description, vegetarian, price); 
menulItems.put (menuItem.getName(), menultem); 
} € the key: X th 
ey is . e value is the menultem ob; 
Y's the item an m object. 


public Hashtable getItems() 


{ 
return menultems; ame 
} We're not Going to 


need this anymore. 


G harpen our pencil 
“4 } 


Before looking at the next page, quickly jot down the three things 
we have to do to this code to fit it into our framework: 
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Reworking the Café Menu code 


Integrating the Cafe Menu into our framework is easy. Why? Because 
Hashtable is one of those Java collections that supports Iterator. But it’s not 
quite the same as ArrayList... 
CafeMenu implements the Menu 


mS interface, so the Waitress can use it 


just like the other two Menus. 


public class CafeMenu implements Menu { 
Hashtable menuItems = new Hashtable(); 


ee We've using Hashtable because it’s a 
pubis fesen 4 Common data structure for storing values; 


// constructor code here You tould also use the newer HashMap. 


} 


public void addItem(String name, String description, 
boolean vegetarian, double price) 


{ 


MenulItem menuItem = new Menultem(name, description, vegetarian, price); 
menultems.put (menuItem.getName(), menultem) ; 


[ i t|tems() so we dont 
Just like before, we Can get vid of ge 
aeciiviniiennie miei ma Mal ae the implementation of menultems to the Waitress. 


eset 
== 
blic Iterat Gereeae f=— And here’s where we implement the eveatelterator() 
Si ee ee ait ee iene 0; method. Notice that we're not getting an [terator 


for the whole Hashtable, just for the values. 


: a 


Cade Up Clase Hashtable is a little more complex than the ArrayList because it 
supports both keys and values, but we can still get an Iterator 


for the values (which are the Menultems). 


public Iterator createIterator() { 
return menulItems.values().iterator() ; 


First we get the values of the Hashtable, i metily that collection supports the 
which is just a collection of all the ates method, which returns a 
objects in the hashtable. object of type java.util. Lerator. 
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test drive the new menu 


Adding the Café Menu to the Waitress 


That was easy; how about modifying the Waitress to support our new Menu? 
Now that the Waitress expects Iterators, that should be easy too. 


; The Café menu is passed into the Waitress in 
ers ee ee the constructor with the other menus, and we 
oo stash it in an instance variable. 


Menu dinerMenu; 

Menu cafeMenu; 

public Waitress (Menu pancakeHouseMenu, Menu dinerMenu, Menu cafeMenu) { 
this.pancakeHouseMenu = pancakeHouseMenu; 


this.dinerMenu = dinerMenu; 
this.cafeMenu = cafeMenu; 


public void printMenu() { 
Iterator pancakelIterator = pancakeHouseMenu.createlIterator(); 
Iterator dinerIterator = dinerMenu.createlIterator(); 


Iterator cafelterator = cafeMenu.createlIterator(); <—_—_ We've using the Cafe's 
menu for our dinner menu. 

System.out.printin (“MENU\n----\nBREAKFAST”) ; All we have to do to print 

printMenu (pancakeIterator) ; it is create the iterator, 


System. out.println(“\nLUNCH”) ; 


printMenu (dinerIterator) ; ~~ and pass it to printMenu(). 
That’s it! 


System.out.println(“\nDINNER”) ; 
printMenu (cafelIterator) ; 


privars void printMenu(Iterator iterator) { ~— Nothing changes here 
while (iterator.hasNext()) { 
MenuItem menuItem = (MenulItem) iterator.next(); 
System.out.print (menultem.getName() + “, “); 
System.out.print (menultem.getPrice() + “ -- “); 
System.out.printlin(menultem.getDescription()); 
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Breakfast, lunch AND dinner 


Let’s update our test drive to make sure this all works. 


public class MenuTestDrive { 
public static void main(String args[]) { Create a CafeMenw... 


PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu () ; 
DinerMenu dinerMenu = new DinerMenu(); e———— 
CafeMenu cafeMenu = new CafeMenu(); .. and pass it to the waitress. 


Waitress waitress = new Waitress (pancakeHouseMenu, dinerMenu, cafeMenu) ; a2) 


waitress.printMenu 


(); < Now, when we print we should see all three menus. 


Here's the test run: check out the new dinner menu from the Café! 


File Edit Window Help Kathy&BertLikePancakes 


% java DinerMenuTestDrive First we iterate 


MENU through the pancake 
---- menu. 
BREAKFAST 


K&B’s Pancake Breakfast, 2.99 -- Pancakes with scrambled eggs, and toast 

Regular Pancake Breakfast, 2.99 -- Pancakes with fried eggs, sausage 

Blueberry Pancakes, 3.49 -- Pancakes made with fresh blueberries And then 
Waffles, 3.59 -- Waffles, with your choice of blueberries or strawberries the diner 


LUNCH menu. 
Vegetarian BLT, 2.99 -- (Fakin’) Bacon with lettuce & tomato on whole wheat 

BLT, 2.99 -- Bacon with lettuce & tomato on whole wheat 

Soup of the day, 3.29 -- Soup of the day, with a side of potato salad 

Hotdog, 3.05 -- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice, 3.99 -- Steamed vegetables over brown rice 
Pasta, 3.89 -- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


DINNER Qh find finally the 
Soup of the day, 3.69 -- A cup of the soup of the day, with a side salad  vrew tafe menu, 
Burrito, 4.29 -- A large burrito, with whole pinto beans, salsa, guacamole all with the 
Veggie Burger and Air Fries, 3.99 -- Veggie burger on a whole wheat bun, same iteration 
lettuce, tomato, and fries tode. 


% 
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what did we do? 


What did we do? 


ArrayList 


Earns (20 
i 


we a iterate over menu items... enue 7 7 
5 different implementations 
. and two different 


) anterfaces Lor iterating: 
and we didn’t want her to a 


know about how the menu 


[ items are implemented. 


We decoupled the Waitress.... 


ArrayList has 3 
So we gave the Waitress an built in therator- 


Menace | Menatre® 


Iterator for each kind of ArrayList 


group of objects she needed to N 


iterate over... .. one for 


\ ArrayList. ” 


| Menatxe® | 


1 


- Aeray doesn’t 
| Treratt have a built in 
.. and one for Iterator so we 
Array. built our own. 


a 


<< Now she doesn’t have to worry about which 
implementation we used; she always uses the same 
interface — Iterator — to iterate over menu items. 
She’s been decoupled from the implementation. 


——— 
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Array 


Menitre® 


Menitxo® 


Menarre® 


Menasre® | Yenurre® | Menarre™ | 
3 
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... and we made the Waitress more extensible 


By giving her an Iterator 
we have decoupled her from 
the implementation of the 
menu items, so we Can easily 
add new Menus if we want. 


ly 
next () oe 


Cause now she ¢ 
Same Code to ta 
any group of objects. And 
it’s bette, for us because 
the implementation details 
arent exposed. 


But there’s more! 


Java gives you a lot of 
“collection” classes that allow 
you to store and retrieve 
groups of objects. For example, 


aaa 
sy 
Vector 


Veetor and LinkedList. 


‘ Most have different 


interfaces. 


Which is bette, Lor her, LerorF 


| Menare™ | Menirre® | Mente | Mente | 


We easily added another 
implementation of menu 
items, and since we 
provided an |terator, 


the Waitress knew what 


Hashtable + do. 
oe *O 


key Menitxo™ 


a\ 


Men irre 


Making an Iterator 
for the Hashtable 
values was easy; when 
you call 


Ne values.iterator() 
you get an 
Iterator. 


entre 


LinkedList 


Menigxe®™ 


Menace — entre 


Men irre 


OQ 


But almost all of 
them support a way 
to obtain an [terator: 


4 


And if they don’t support 
Iterator, that’s ok, because now 
you know how to build your own. 
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iterators and collections 


Iterators and Collections 


We've been using a couple of classes that are part of the Java Collections Framework. 
This “framework” is just a set of classes and interfaces, including ArrayList, which we’ve 
been using, and many others like Vector, LinkedList, Stack, and PriorityQueue. Each 
of these classes implements the java.util.Collection interface, which contains a bunch of 


useful methods for manipulating groups of objects. 


Let’s take a quick look at the interface: 


<<interface>> 
Collection 


add() 


fis you tan see, there's all kinds of good 
stuff here: You can add and remove 


aadAll() elements from your collection without even 
clear() Lindon Kowit re implemented: 

contains() 

containsAll() 

equals() 

hashCode() 


Here’s our old friend, the iterator() 
method. With this method, You can get 
an Iterator for any Class that implements 
the Collection interface. 


isEmpty() 
iterator() 
remove() 
removeAll) 
retainAll() 
size() 
toArray() 


Other handy methods in¢lude size(), 


to get the number of elements, 
and toArray() to turn Your 
collection into an array. 


The nice thing about Collections and 
Iterator is that each Collection object 
knows how to create its own Iterator. 
Calling iterator() on an ArrayList returns a 
concrete Iterator made for ArrayLists, but 
you never need to see or worry about the 
concrete class it uses; you just use the 
Iterator interface. 
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Watch it! 


Hashtable is one of a few 
classes that indirectly 
supports Iterator. As you saw 
when we implemented the 
CafeMenu, you could get an 
Iterator from it, but only by 
first retrieving its Collection 
called values. If you think 
about it, this makes sense: 
the Hashtable holds two 
sets of objects: keys and 
values. If we want to iterate 
over its values, we first need 
to retrieve them from the 
Hashtable, and then obtain 
the iterator. 
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Iterators and Collections 
in Java 9 


Check this out, in 
Java 5 they've added 
support for iterating 
over Collections so that 
you don't even have to 
ask for an iterator. 


Java 5 includes a new form of the for statement, called 
for /in, that lets you iterate over a collection or an array 
without creating an iterator explicitly. 


To use for/in, you use a for statement that looks like: 


obj is assigned to the next 
clement in the collection each 
Lime through the loop. 


Iterates over 
each object in 
the collection. 


\ 


for (Object obj: collection) { 


} 
Load uP an 
: oe ee eae ArrayList of 
Here’s how you iterate over an ArrayList using for/in: Weve tbe: 
ArrayList items = new ArrayList(); ) 


items.add(new MenuItem(“Pancakes”, “delicious pancakes”, true, 1.59); 
items.add(new MenulItem(“Waffles”, “yummy waffles”, true, 1.99); 
items.add(new MenulItem(“Toast”, “perfect toast”, true, 0.59); 


for (Menultem item: items) { 
System.out.printlin(“Breakfast item: “ + item); 


} 


Iterate over the list and print 
each item. Watch it! 


You need to use Java 5’s new 


generics feature to ensure for/ 
in type safety. Make sure you 
read up on the details before 
using generics and for/in. 
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code magnets 


Code Magnets 


250 \ The Chefs have decided that they want to be able to alternate their lunch menu items; in other words, 

—_ they will offer some items on Monday, Wednesday, Friday and Sunday, and other items on Tuesday, 
Thursday, and Saturday. Someone already wrote the code for a new “Alternating” DinerMenu Iterator 
so that it alternates the menu items, but they scrambled it up and put it on the fridge in the Diner as a 
joke. Can you put it back together? Some of the curly braces fell on the floor and they were too small 
to pick up, so feel free to add as many of those as you need. 


MenuItem menultem = items[position]; 


position = position + 2; 
return menultem; 


import java.util.Iterator; 
import java.util.Calendar; 


Public Object next() { 


public AlternatingDinerMenulIterator (MenuItem[] 


items) 


this.items = items; 


Calendar rightNow = Calendar.getInstance(); 


position = rightNow. get (Calendar. DAY OF W. 


implements Iterator 


Menultem[] items; 
int position; 


K) % 2; 


public void remove () { 


public class AlternatingDinerMenulIterator 


public boolean hasNext() { 


throw new UnsupportedOperationException ( 
“Alternating Diner Menu Iterator does not support remove()”); 


if (position >= items.length || items[position] == null) { 
return false; 
} else { 


return true; 
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Is the Waitress ready for prime time? 


The Waitress has come a long way, but you’ve gotta admit 
those three calls to printMenu() are looking kind of ugly. 


Let’s be real, every time we add a new menu we are going to 
have to open up the Waitress implementation and add more 
code. Can you say “violating the Open Closed Principle?” 


Three ereatelterator() calls. 


public void printMenu() { 
Iterator pancakelIterator = pancakeHouseMenu.createlIterator(); 
Iterator dinerIterator = dinerMenu.createlIterator (); 
Iterator cafelIterator = cafeMenu.createlIterator(); 


System. out.println (“MENU\n----\nBREAKFAST”) ; 
printMenu (pancakelIterator) ; 


System.out.println(“\nLUNCH”) ; \ ; 

printMenu (dinerIterator) ; Three calls to print Menu. 
a 

System. out.println(“\nDINNER”) ; =m 


printMenu (cafelIterator) ; 


Everytime we add or remove a menu we're going, 
to have to open this code up for changes. 


It’s not the Waitress’ fault. We have done a great job of decoupling the menu implementation and 
extracting the iteration into an iterator. But we still are handling the menus with separate, independent 
objects — we need a way to manage them together. 


RAIN 
POWER 


The Waitress still needs to make three calls to printMenu(), one for each menu. Can you think of a 
way to combine the menus so that only one call needs to be made? Or perhaps so that one Iterator is 
passed to the Waitress to iterate over all the menus? 
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This isn't so bad, all we 
need to do is package 
the menus up into an ArrayList 
and then get its iterator to iterate 
through each Menu. The code in the 
Waitress is going to be simple 
and it will handle any number of 
menus. 


Sounds like the chef is on to something. Let’s give it a try: 


public class Waitress { ~~ Now pear ae an 
ArrayList menus; AvrayList menue? 
public Waitress(ArrayList menus) { 
this.menus = menus; 
} find we iterate 
through the 
public void printMenu() { . menus, passing each 
Iterator menulterator = menus.iterator(); i 
menu s iterator 
while (menuIterator.hasNext()) { 
7 to the overloaded 
Menu menu (Menu) menulterator.next(); int 0 
printMenu(menu.createIterator()); printMenul) method. 
} 
} 
void printMenu(Iterator iterator) { Zx—~ 
while (iterator.hasNext()) { No eode 
MenuItem menuItem = (MenulItem) iterator.next(); changes here. 
System.out.print (menultem.getName() + “, “); 
System.out.print (menultem.getPrice() + “ -- “); 
System.out.printlin(menultem.getDescription()); 


This looks pretty good, although we’ve lost the names of the menus, 
but we could add the names to each menu. 
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Just when we thought it was safe... 


Now they want to add a dessert submenu. 


I just heard the 
Diner is going to be 
creating a dessert menu that 
is going to be an insert into 
their regular menu. 


Okay, now what? Now we have to support not only multiple 
menus, but menus within menus. 


It would be nice if we could just make the dessert menu an 
element of the DinerMenu collection, but that won’t work as 
it is now implemented. 


Oo = 
What we want (something like this): 7 ¢ 


All Menus 


% i } 
| “Raker oP | “Nerme | —afemen | 
1 2 3 


Here’s our Avraylist 
that holds the menus 
of each restaurant. 


Café Menu 


Pancake Menu 
Diner Menu 


9999 


| “ener |“ ae a | 


Hashtable 
SY 


eae Dessert Menu 


We need for Diner Menu to hold a submenu, but 


we can’t actually assign a menu to a Menultem 
a array because the types are different, so this 
isnt going, to work. 


i We can’t assign a dessert menu to 
wor 
a Menultem array. 


Time for a change! 
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time to refactor 


What do we need? 


The time has come to make an executive decision to 
rework the chef’s implementation into something that 
is general enough to work over all the menus (and now 
sub menus). That’s right, we’re going to tell the chefs 
that the time has come for us to reimplement their 
menus. 


The reality is that we’ve reached a level of complexity 
such that if we don’t rework the design now, we’re 
never going to have a design that can accommodate 
further acquisitions or submenus. 


So, what is it we really need out of our new design? 


= We need some kind of a tree shaped structure that 
will accommodate menus, submenus and menu 
items. 


We need to make sure we maintain a way to 
traverse the items in each menu that is at least 
as convenient as what we are doing now with 
iterators. 


We may need to be able traverse the items in a 
more flexible manner. For instance, we might 
need to iterate over only the Diner’s dessert menu, 


or we might need to iterate over the Diner’s entire 


There comes atime 
when we must refactor 
our code in order for it to grow. 
To not do so would leave us with 
rigid, inflexible code that has 
no hope of ever sprouting 
new life. 


menu, including the dessert submenu. 
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Because we need to represent 


menus, nested sul menus 4 és 
menu items, we Can naturally i 
them in a tree—like structure. — 


wee a a ee 
2 2 getomodate Menws.-- 
g ~Y 1 Oiner ne 


“7 
he \, .. and sub menus... Ofe ae 
Men ire Mente Mente Men iryo® Mente Men rr m,) Menrre® Menarre® Menarre® 
€Ssert NS 


Menare® Pn A A sY/ 


We still need to be able 

ko traverse the all the 

“ee We also need to be able to 
Vaverse more flexibly, t 


inst 


ne over One meny 


ra) 


Ssert 1 


Q Q ie O 


fenarre® 


oe RAIN 
PQWER 


How would you handle this new wrinkle to our design requirements? Think about it before turning the page. 
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composite pattern defined 


The Composite Pattern defined 


That’s right, we’re going to introduce another pattern 
to solve this problem. We didn’t give up on Iterator — it 
will still be part of our solution — however, the problem 
of managing menus has taken on a new dimension that 
Iterator doesn’t solve. So, we’re going to step back and 
solve it with the Composite Pattern. 


We're not going to beat around the bush on this pattern, 
we're going to go ahead and roll out the official definition 
now: 


The Composite Pattern allows you to 
compose objects into tree structures to 
represent part-whole hierarchies. Composite 


lets clients treat individual objects and 
compositions of objects uniformly. 


Let’s think about this in terms of our menus: this pattern 
gives us a way to create a tree structure that can handle 

a nested group of menus and menu items in the same 
structure. By putting menus and items in the same 
structure we create a part-whole hierarchy; that 1s, a tree of 
objects that is made of parts (menus and menu items) but 
that can be treated as a whole, like one big tber menu. 


Once we have our tiber menu, we can use this pattern 

to treat “individual objects and compositions uniformly.” 
What does that mean? It means if we have a tree structure 
of menus, submenus, and perhaps subsubmenus along with 
menu items, then any menu is a “composition” because 

it can contain both other menus and menu items. The 
individual objects are just the menu items — they don’t hold 
other objects. As you'll see, using a design that follows the 
Composite Pattern is going to allow us to write some simple 
code that can apply the same operation (like printing!) over 
the entire menu structure. 
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tree structure: 
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the iterator and composite patterns 


The Composite Pattern 
allows us to build structures 
of objects in the form of 
trees that contain hoth 
compositions of objects and 
individual objects as nodes. 


Using a composite structure, 
we can apply the same 
operations over both 
composites and individual 
objects. In other words, in 
most cases we can ignore 
the differences hetween 
compositions of objects and 
individual objects. 


px tre var 


youarehere > 357 


composite pattern class diagram 


The Client uses the 


. £ nodes: 
Component in sie the Composite and the lear no 
manipulate the objects 
Composition: \ 

Client Component 
operation() 
add(Component) 

Note that the Leaf als remove(Component) 
° 4 a 
inherits methods like add() getChild(int) 


removel) and getChildO, which 


don’t necessaril make a lot of 
sense for g leat node. We've 


going to ome back to this issue. 


es an 


fin 
The Component de i 
interface for all objects in 
the Composition’ both the 


The Component 
default behavior 
getChildO and 


may implement a 
for add(), remove(), 
its operations. 


Leaf Composite 
operation() add(Component) 
so 
A Leaf ha nf oo The Comte eal 
children. operation() implements Lions: 
related oerations 
Note that some oF 
A Leaf defines the behavior for the ghese may Seah 
clements in the composition. It does ; ; f, se on a = an 
this by implementing the operations The Composite’s role is to dexine ain that pec a 
the Composite supports. behavior of the Components . exception id 
having children and te store child erate 


Q: Component, Composite, Trees? 
I’m confused. 


A: A composite contains components. 


Components come in two flavors: 
composites and leaf elements. Sound 
recursive? Itis. Acomposite holds a set 
of children, those children may be other 
composites or leaf elements. 
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components. 


thereyare 


Dumb’ Questions 


When you organize data in this way you end 
up with a tree structure (actually an upside 
down tree structure) with a composite at the 
root and branches of composites growing up 
to leaf nodes. 


: How does this relate to iterators? 


A: Remember, we’re taking a new 
approach. We’re going to re-implement the 
menus with a new solution: the Composite 
Pattern. So don’t look for some magical 
transformation from an iterator to a 
composite. That said, the two work very 
nicely together. You'll soon see that we 
can use iterators in a couple of ways in the 
composite implementation. 


the iterator and composite patterns 


Designing Menus with Composite 


So, how do we apply the Composite Pattern to our menus? ‘To start with, we need to create a 


component interface; this acts as the common interface for both menus and menu items and allows 


us to treat them uniformly. In other words we can call the same method on menus or menu items. 


Now, it may not make sense to call some of the methods on a menu item or a menu, but we can deal 
with that, and we will in just a moment. But for now, let’s take a look at a sketch of how the menus 
are going to fit into a Composite Pattern structure: 


use the 


ee 
The Waitress 15 9° ee to actess 


inte 
MensComronere, Menthe 


both Menus 2 ny 


a 


Here ave the methods for Ss 


manipulating the Components. 


The components are 
Menultem and Menu. 


Both Menultem and Menus 
override print(). 


‘ag 


Menultem overrides the methods d, make 
the default implementa 


sense, and uses 


in MenuComponent Lor 


sense (like add() — it doesn’t 


MenuComponent represents the interface for 

both Menultem and Menu. We've used an abstract 
class here because we want to provide default 
implementations for these methods. 


MenuComponent 


getName() 
getDescription() 
getPrice() 
isVegetarian() 

print() 
add(Component) 
remove(Component) 
getChild(int) 


Menultem Menu 
getName() menuComponents 
getDescription() getName() 
getPrice() getDescription() 
isVegetarian() print() 


print() 


tions 


add(Component) 
remove(Component) 
getChild(int) 


Menu also overrides th 
sense, like a way to ad 
(or other menus!) from its 


use the getNamel) and 
methods to return the name 


In addition, we'll 
getD estription() 


We have some of the same 
methods you'll remember 
from our Previous versions 
of Menultem and Menu, 
and we've added print (), 
add(), removel) and 
getChild(). We'll deseribe 
these soon, when we 
implement our new Menu 
and Menultem classes. 


e methods that make 


d and remove menu items 


menuComponents. 


and description of the menu. 


359 


you are here > 


implementing composite men 


Implementing the Menu Component 


Okay, we’re going to start with the 
MenuComponent abstract class; remember, the 
role of the menu component is to provide an 
interface for the leaf nodes and the composite 
nodes. Now you might be asking, “Isn’t the 
MenuComponent playing two roles?” It might 
well be and we’ll come back to that point. 
However, for now we’re going to provide a default 
implementation of the methods so that if the 
Menultem (the leaf) or the Menu (the composite) 
doesn’t want to implement some of the methods 
(like getChild() for a leaf node) they can fall back 


on some basic behavior: 


ovides default 


MenuComponent. rovides od 


implementations Lor every 


L 


public abstract class MenuComponent { 


public void add(MenuComponent menuComponent) 


throw new UnsupportedOperationException (); 


} 


public void remove (MenuComponent menuComponent) 
throw new UnsupportedOperationException () ; 


} 
public MenuComponent getChild(int i) { 


throw new UnsupportedOperationException (); 


public String getName() { 


public String getDescription() { 


public double getPrice() { 


public boolean isVegetarian() { 


throw new UnsupportedOperationException () ; 


} 


public void print() { 


throw new UnsupportedOperationException (); 
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throw new UnsupportedOperationException (); 


throw new UnsupportedOperationException (); 


throw new UnsupportedOperationException (); 


All components must implement 
the MenuComponent interface; 
however, because leaves and 
nodes have different roles we 


can’t always define a default 
implementation for each 
method that makes sense. 
Sometimes the best you can do 
is throw a runtime exception. 


Because some of these methods only make sense 
for Menultems, and some only make sense for 
Menus, the default implementation is 
UA, res com erpramea That way, 

if Menultem or Menu doesn’t support an 
operation, they don't have to do anything, 


they can just inherit the 
default implementation. 


{ 
\ We've grouped together the 


“composite” methods — that is, 
methods to add, remove and get 
MenuComponents. 


Here are the “operation” methods; 
these ave used by the Menultems- 
[t turns out we Can also use a 
couple of them in Menu too, as 
you'll see in a couple of pages when 
we show the Menu code. 


printQ) is an “operation” method 
that both our Menus and Menultems 
will implement, but we Provide a 
default operation here. 


Implementing the Menu Item 


Okay, let’s give the Menultem class a shot. Remember, 
this is the leaf class in the Composite diagram and it 
implements the behavior of the elements of the composite. 


public class MenuItem 
String name; 
String description; 
boolean vegetarian; 
double price; 


xtends MenuComponent { 


oa 


public MenulItem(String name, 
String description, 
boolean vegetarian, 
double price) 


— 


this.name = name; 
this.description = description; 
this.vegetarian = vegetarian; 
this.price = price; 


public String getName() { 
return name; 


First we need to extend 
the MenuComponent 


the iterator and composite patterns 


I'm glad we're going in 
this direction, I'm thinking this is 
going to give me the flexibility I need 
to implement that crépe menu I've 
always wanted. 


interf ace. 


The constructor just takes the 
name, destription, ete. and 
keeps a reference to them all. 
This is pretty much like our old 
menu item implementation. 


} Here’s our getter methods — just 


like 
public String getDescription() { 
return description; 


public double getPrice() { 
return price; 


public boolean isVegetarian() { 
return vegetarian; 


public void print() { 
System.out.print(“ “ + getName()); 
if (isVegetarian()) { 
System.out.print (“(v)”); 
} 
System.out.println(“, 
System.out.println(™ 


“+ getPrice()); 


our Previous implem entation. 


This is different from the previous implementation. 
Here we've overriding the print() method in the 
MenuComponent class. For Menultem this method 
prints the complete menu entry: name, description, 
price and whether or not it’s veggie. 


2 


-- “ + getDescription()); 
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composite structure 


Implementing the Composite Menu 


Now that we have the Menultem, we just need the composite class, which we’re 
calling Menu. Remember, the composite class can hold Menultems or other Menus. 
There’s a couple of methods from MenuComponent this class doesn’t implement: 
getPrice() and is Vegetarian(), because those don’t make a lot of sense for a Menu. 


Menu is also a MenuComponent, | 

- ee Menu can have ary number of children 
of type MenuComponent, we \l use an 
internal AwrayList to hold these. 


public class Menu extends MenuComponent { 
ArrayList menuComponents = new ArrayList(); 
String name; 


Steingydessuiptien) This is different than our old implementation: 
we're going to give each Menu a name and a 
public Menu(String name, String description) { destription. Before, we just relied on having 
this.name = name; different classes for each menu. 


this.description = description; 


public void add(MenuComponent menuComponent) { 


menuComponents.add(menuComponent) ; bade how you add Welter 
a other Menus to a Menw. Because 
both Menultems and Menus are 
public void remove (MenuComponent menuComponent) { MenuComponents, we just cad ond 
menuComponents. remove (menuComponent) ; method ty do ie 


} 
You tan also remove a MenuComponent 
public MenuComponent .gecChild(int.4) 4 or get a MenuComponent. 
return (MenuComponent)menuComponents.get (i); 


} 
Here ave the getter methods for getting the name and 


public String getName() { a description. 


return name; 


Notice, we aren't overriding getPrice() or isVegetarian() 
because those methods don’t make sense for a Menu 
sitll Beene ceeetinceeuinagh 1 (although you could argue that isVegetarian() might make 
eotuen description: sense). [f someone tries to call those methods on a Menu, 
; they'll get an UnsupportedOperationExeeption. 


public void print() { 
System.out.print(“\n” + getName ()); 
System.out.printlin(“, “ + getDescription()); 
System.out.printin (“--------------------- m3 To print the Menu, we print the 


| Menw’s name and deseription. 
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Wait a sec, I don't understand the 
implementation of print(). I thought I was 
supposed to be able to apply the same operations to a 
composite that I could to a leaf. If I apply print() to a 
composite with this implementation, all I get is a 
simple menu name and description. I don't get a 
printout of the COMPOSITE. 


Excellent catch. Because menu is a composite and contains 
both Menu Items and other Menus, its print() method should 
print everything it contains. If it didn’t we'd have to iterate 
through the entire composite and print each item ourselves. 
That kind of defeats the purpose of having a composite 
structure. 


As you’re going to see, implementing print() correctly 1s easy 
because we can rely on each component to be able to print 
itself It’s all wonderfully recursive and groovy. Check it out: 


Fixing the print() method 


public class Menu extends MenuComponent { 
ArrayList menuComponents = new ArrayList(); 
String name; 
String description; 


// constructor code here 


All we need to do is change the print() method to 


. ion about this 
// other methods here make it print not, only oe SS other 
Menu, but all of this Menus Comp 
public void print() { Menus and Menultems: 
System.out.print(“\n” + getName ()) ; 
System.out.printlin(“, “ + getDescription()); 
System.out.println (“--------------------- Ww \ 


Iterator iterator = menuComponents.iterator (); ya Lock! We get to use an Iterator. We 
while (iterator.hasNext()) { use it to iterate through all the Menv’s 


MenuComponent HEINE ON SG Moe = components... those could be other Menus, or 
(MenuComponent) iterator.next (); 


i they tould be Menultems. Sinee both Menus 
c es r 
} ee Re and Menultems implement print(), we just 
} all print() and the vest is up to them. 


NOTE: If, during this iteration, we entounter another Menu 
object, its print() method will start another iteration, and so on. 
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test drive {he menu composite 


Getting ready for a test drive... 


It’s about time we took this code for a test drive, but we need to update the Waitress code before 
we do ~ after all she’s the main client of this code: 


Yor! The Waitress code veally is his simple. 
a SConponent al IMe Now we just hand her the top level menu 
an tomponent, the one that contains all the 
talled that allMenus. 
public Waitress (MenuComponent allMenus) { other menus. We've 


this.allMenus = allMenus; 


} 


All she has to do to print the entire menu 
public void printMenu() { ne 


hierarchy — all the menus, and all the menu 
allMenus.print(); items — is ¢all print) on the top level menu. 
} 


We're gonna have one happy Waitress. 


Okay, one last thing before we write our test drive. Let’s get an idea of what the menu 
composite is going to look like at runtime: 


Every Menu and ts level menu holds all 
Menultem implements the and items. 
MenuComponent interface. Composite 


oa 


All Neo? 
a Ka @ eee 
Each Menu 
2 holds items... 
S KZ Composite 
i> tol ..or items and ine © Compost 


Cafe We 
Pa | x other menus. i pi 2 az s. 
Menirre® Mente Mento Mente QO Q ©. Menarre® 


Mente Mento 
Cosson NE 
Pa 


mE a. 9 a 


Yen are Men are Ueno 
ena nue nuTx@ *nuTr@ 


Ca 
Leaf 
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Now for the test drive... 


Okay, now we just need a test drive. Unlike our previous version, we’re going to 
handle all the menu creation in the test drive. We could ask each chef to give us 
his new menu, but let’s get it all tested first. Here’s the code: 


public class MenuTestDrive { 
public static void main(String args[]) { ete Crest eveate all 
enuComponent pancakeHouseMenu = —— Bie wien objects. 
new Menu (“PANCAKE HOUSE MENU”, “Breakfast”) ; 
enuComponent 
new Menu ( 
enuComponent 
new Menu(“CAFE MI 
( 


dinerMenu = 


“DINER MENU”, “Lunch”) ; We also need a toP level 


) 
NU”, “Dinner”) ; menu that well name 
v , 
nu = allMenus. 
“DESSERT MENU”, “Dessert of course!”); 


enuComponen 
new Menu 


MenuComponent allMenus = new Menu(“ALL MENUS”, “All menus combined”) ; 


We're using the Composite add() method to add 


allMenus.add(pancakeHouseMenu) ; 
E—— each menu to the top level menu, all Menus. 


allMenus.add(dinerMenu) ; 
allMenus.add(cafeMenu) ; 


Now we need to add all 


) 
Z— he menu items, heres one 
// add menu items her 4 
example, for the rest, look at 

dinerMenu.add(new MenuItem ( the complete source Code. 

“Pasta”, 

“Spaghetti with Marinara Sauce, and a slice of sourdough bread”, 

true, 


3.89) )i And we're also adding a menu toa 
| | ae ae menu. fill dinerMenu Cares about is that 
-p) 
a a i 8 everything, it holds, whether it’s a menu 
item or a meny, IS a MenuComponent: 
dessertMenu.add(new MenuItem ( 
“Apple Pie”, 


“Apple pie with a flakey crust, topped with vanilla ice cream”, 
true, 


1.59)); Me Add some apple pie to the 


dessert menu... 


// add more menu items her 


‘ . = : . ? 
Waitress waitress new Waitress (allMenus) ; é~ Once we've constructed our Pe ee 


menu hierarch’ 
waitress.printMenu () ; y we hand the whole 


| thing to the Waitress, and as you've 


seen, it's easy as apple pie for her 
to print it out. 
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Getting ready for a test drive... 


NOTE: this output is based on the complete source. 


File Edit Window Help GreenEggs&Spam 
% java MenuTestDrive 


ALL MENUS, All menus combined 


ae Here’s all our menus... we printed all this 


just by calling print0) on the top level menu 


K&B’s Pancake Breakfast(v), 2.99 

-- Pancakes with scrambled eggs, and toast 
Regular Pancake Breakfast, 2.99 

-- Pancakes with fried eggs, sausage 
Blueberry Pancakes(v), 3.49 


-- Pancakes made with fresh blueberries, and blueberry syrup 
Waffles(v), 3.59 


-- Waffles, with your choice of blueberries or strawberries 


DINER MENU, Lunch 


Vegetarian BLT(v), 2.99 


-- (Fakin’) Bacon with lettuce & tomato on whole wheat 
BLT, 2.99 


-- Bacon with lettuce & tomato on whole wheat 
Soup of the day, 3.29 


-- A bowl of the soup of the day, with a side of potato salad 
Hotdog, 3.05 


-- A hot dog, with saurkraut, relish, onions, topped with cheese 
Steamed Veggies and Brown Rice(v), 3.99 

-- Steamed vegetables over brown rice 
Pasta(v), 3.89 


-- Spaghetti with Marinara Sauce, and a slice of sourdough bread 


DESSERT MENU, Dessert of course! The new dessert 
L—_ menu is printed 
Apple Pie(v), 1.59 whentwerave 
-- Apple pie with a flakey crust, topped with vanilla icecream se aie 
Cheesecake(v), 1.99 printing all the 


-- Creamy New York cheesecake, with a chocolate graham crust Diner menu 
Sorbet(v), 1.89 components 


-- A scoop of raspberry and a scoop of lime 


CAFE MENU, Dinner 


Veggie Burger and Air Fries(v), 3.99 


-- Veggie burger on a whole wheat bun, lettuce, tomato, and fries 
Soup of the day, 3.69 


-- A cup of the soup of the day, with a side salad 
Burrito(v), 4.29 


-- A large burrito, with whole pinto beans, salsa, guacamole 
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What's the story? First you tell us 
One Class, One Responsibility, and now you 
are giving us a pattern with two responsibilities 
in one class. The Composite Pattern manages 

a hierarchy AND it performs operations 
related to Menus. 


There is some truth to that observation. We could say that the 
Composite Pattern takes the Single Responsibility design principle and 


trades it for transparency. What’s transparency? Well, by allowing the 
Component interface to contain the child management operations and 
the leaf operations, a client can treat both composites and leaf nodes 
uniformly; so whether an element is a composite or leaf node becomes 
transparent to the client. 


Now given we have both types of operations in the Component 

class, we lose a bit of safety because a client might try to do something 
inappropriate or meaningless on an element (like try to add a menu 

to a menu item). This 1s a design decision; we could take the design in 
the other direction and separate out the responsibilities into interfaces. 
This would make our design safe, in the sense that any inappropriate 
calls on elements would be caught at compile time or runtime, but we’d 
lose transparency and our code would have to use conditionals and the 
instanceof operator. 


So, to return to your question, this is a classic case of tradeoff. We are 
guided by design principles, but we always need to observe the effect 
they have on our designs. Sometimes we purposely do things in a way 
that seems to violate the principle. In some cases, however, this is a 
matter of perspective; for instance, it might seem incorrect to have 
child management operations in the leaf nodes (like add(), remove() and 
getChild()), but then again you can always shift your perspective and see 
a leaf as a node with zero children. 


flashback to iferator 


Flashback to Iterator 


We promised you a few pages back that we’d show you how to use Iterator 
with a Composite. You know that we are already using Iterator in our internal 
implementation of the print() method, but we can also allow the Waitress to 
iterate over an entire composite if she needs to, for instance, if she wants to go 
through the entire menu and pull out vegetarian items. 


To implement a Composite iterator, let’s add a createIterator() method in every 
component. We’ll start with the abstract MenuComponent class: 


MenuComponent 
seotblariet We've added a ereatelterator() method 
getDescription() to the MenuComponent. This means 
getPrice() that each Menu and Menultem will 
isVegetarian() need to implement this method. It also 
print) means that Calling ereatelterator() on a 
oe composite should apply to all children of 
remove(Component) : 
getChild(int) the composite. 
createlterator() 


Now we need to implement this method in the Menu and Menultem classes: 


Here we're using a new iterator called 
Compositelterator. [+ knows how to 


// other code here doesn’t change ye iterate over any Composite. We pass it 
the current composite’s iterator. 


public class Menu extends MenuComponent { 


public Iterator createIterator() { 
return new CompositeIterator (menuComponents.iterator()); 


public class MenuItem extends MenuComponent { 


// other code here doesn’t change Now for the Menultem... 


public Iterator createIterator() { Y. rf What's this Nulllterator? 
return new NullIterator(); oull see in two pages. 
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The Composite Iterator 


The Compositelterator is a SERIOUS iterator. It’s got the job of iterating 
over the Menultems in the component, and of making sure all the child 
Menus (and child child Menus, and so on) are included. 


Here’s the code. Watch out, this isn’t a lot of code, but it can be a little mind 
bending, Just repeat to yourself as you go through it “recursion is my friend, 


recursion is my friend.” ) 
Like all iterators, we re WATCH (ut: 


: entin e jay util. [terator _ j 
C oe RECURSION 
ZONE ANEAD 


import java.util.*; 


public class CompositelIterator implements Iterator { The iterator of the top level 


Stack stack = new Stack(); Composite we're going to iterate over 
is passed in. We throw that in a stack 
data structure. 


public CompositelIterator (Iterator iterator) { 
stack.push (iterator) ; 


} Okay, when the ¢lient wants 
supide-Gusect ndak(). 4 —_— i the next element we 
if (hasNext()) { ist make sure there is one 
Iterator iterator = (Iterator) stack.peek(); by calling hasNext()... 
MenuComponent component = (MenuComponent) iterator.next(); 
if (component instanceof Menu) { 
stack.push(component. telIt t ; , 
} e a alae aac \ If there is a next element, we get 
return component; the current iterator off the stack 
} else { and get its next element. 
return null; 
} If that element is a menu, we have 
: another Composite that needs to 
be included in the iteration, so we 
public boolean hasNext() { throw it on the stack. In either 
if (stack.empty()) { tase, we return the component. 
} ie ere To see if there is a next element, 
Iterator iterator = (Iterator) stack.peek(); we check to see if the stack is 
if (l!iterator.hasNext()) { empty; if so, there isn’t. 
stack.pop(); NK Otherwise, we get the iterator off 
return hasNext(); the top of the stack and see if it 
} else { has a next element. [f it doesn't 
} 5 cicada Otherwise there is a next element —we por it off the stack and call 
} and we return true. hasNext() recursively. 
} 
public void remove() { , : 
throw new UnsupportedOperationException (); Were not supporting 
} remove, just traversal. 
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be 


That is serious code... I'm trying 
to understand why iterating over 
a composite like this is more difficult 
than the iteration code we wrote for 
print() in the MenuComponent class? 


When we wrote the print() method in the 
MenuComponent class we used an iterator to 
step through each item in the component and if 
that item was a Menu (rather than a Menultem), 
then we recursively called the print() method to 
handle it. In other words, the MenuComponent 
handled the iteration itself} internally. 


With this code we are implementing an external 
iterator so there is a lot more to keep track of. 

For starters, an external iterator must maintain its 
position in the iteration so that an outside client 
can drive the iteration by calling hasNext() and 
next(). But in this case, our code also needs to 
maintain that position over a composite, recursive 
structure. That’s why we use stacks to maintain 
our position as we move up and down the 
composite hierarchy. 
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RAIN 
POWER 


Draw a diagram of the Menus and Menultems. Then pretend you are the Compositelterator, and your job is 
to handle calls to hasNext() and next(). Trace the way the Compositelterator traverses the structure as this 
code is executed: 


public void testCompositelIterator(MenuComponent component) { 
CompositelIterator iterator = new CompositelIterator(component.iterator) ; 


while (iterator.hasNext()) { 
MenuComponent component = iterator.next(); 
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The Null Iterator 


Okay, now what is this Null Iterator all about? Think about it this way: a 
Menultem has nothing to iterate over, right? So how do we handle the le of the 
implementation of its createlterator() method? Well, we have two choices: NOTE: Another cept ie 
Null Object “Design Pattern. 
Choice one: 
Return null 


We could return null from createlterator(), but then we’d 
need conditional code in the client to see if null was 
returned or not. 


Choice two: 


Return an iterator that always returns 
false when hasNext() is called 


This seems like a better plan. We can still return an iterator, but 
the client doesn’t have to worry about whether or not null is ever 
returned. In effect, we’re creating an iterator that is a “no op”. 


The second choice certainly seems better. Let’s call it NullIterator and 
implement it. 


This is the laziest [terator you've 
ever seen, at every step of the 
import java.util.Iterator; way it punts. 


public class NullIterator implements Iterator { 


public Object next() { 


return null; <—_ When next) is called, we return null. 
} 
public boolean hasNext() { ie Most importantly when hasNext() is 
return false; called we always return false. 


} 


public void remove() { 


t think 
throw new UnsupportedOperationException(); €— And the Nulllterator wouldnt thin 
} of supporting remove. 
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Give me the vegetarian menu 


Now we've got a way to iterate over every item of the Menu. Let’s 
take that and give our Waitress a method that can tell us exactly 
which items are vegetarian. 


public class Waitress { 
MenuComponent allMenus; 


public Waitress (MenuComponent allMenus) { 
this.allMenus = allMenus; 


The printVegetarianMenul) method 
takes the allMenu's composite and 


public void printMenu ‘ome gets its iterator. That will be our 
allMenus.print(); Compositel terator. 
} 


public void printVegetarianMenu() { 


Iterator iterator = allMenus.createIterator(); [terate through 
every element of the 
System.out.println(“\nVEGETARIAN MENU\n----”) composite. 


while (iterator.hasNext()) { 


MenuComponent menuComponent = Call each element's 


(MenuComponent) iterator.next(); a) 
isVe etarian 

sg sed true, we tall its 

print) method: 


try { 
if (menuComponent.isVegetarian()) { 
menuComponent.print (); 
} 
} catch (UnsupportedOperationException e) {} ‘ 
print() is only 


} called on Menultems, 
never Composites. 


Can you see why? 
We implemented isVegetarian() on the 
Menus to always throw an exception. |f 


that happens we catch the exception, but 
continue with our iteration. 
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magic of iterator and composite 


The magic of Iterator & Composite together... 


Whooo! It’s been quite a development effort to get our code to this point. Now we've got a general 
menu structure that should last the growing Diner empire for some time. Now it’s time to sit back and 
order up some veggie food: 


| File Edit_Window Help HaveUhuggedYurlteratorfoday? 
% java MenuTestDrive 
VEGETARIAN MENU The Vegetarian Menu tonsists of the 
a=ae vegetarian items from every menu. 
K&B’s Pancake Breakfast(v), 2.99 
-- Pancakes with scrambled eggs, and toast 
Blueberry Pancakes(v), 3.49 
-- Pancakes made with fresh blueberries, and blueberry syrup 
Waffles(v), 3.59 
-- Waffles, with your choice of blueberries or strawberries 
Vegetarian BLT(v), 2.99 
-- (Fakin’) Bacon with lettuce & tomato on whole wheat 
Steamed Veggies and Brown Rice(v), 3.99 
-- Steamed vegetables over brown rice 
Pasta(v), 3.89 
-- Spaghetti with Marinara Sauce, and a slice of sourdough bread 
Apple Pie(v), 1.59 
-- Apple pie with a flakey crust, topped with vanilla ice cream 
Cheesecake (v), 1.99 
-- Creamy New York cheesecake, with a chocolate graham crust 
Sorbet(v), 1.89 
-- A scoop of raspberry and a scoop of lime 
Apple Pie(v), 1.59 
-- Apple pie with a flakey crust, topped with vanilla ice cream 
Cheesecake (v), 1.99 
-- Creamy New York cheesecake, with a chocolate graham crust 
Sorbet(v), 1.89 
-- A scoop of raspberry and a scoop of lime 
Veggie Burger and Air Fries(v), 3.99 
-- Veggie burger on a whole wheat bun, lettuce, tomato, and fries 
Burrito(v), 4.29 
-- A large burrito, with whole pinto beans, salsa, guacamole 
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T noticed in your 
printVegetarianMenu() method that you 

used the try/catch to handle the logic of the 
Menus not supporting the isVegetarian() method. 
I've always heard that isn't good programming 
form. 


| ¥ 


. 
te. — Let’s take a look at what you’re talking about: 


\ sani) on all 
We call isVegetavian' 
MenuComponents, but Menus 
- throw an exception because they 


if (menuComponent.isVegetarian()) { th operation. 
e 


menuComponent.print(); dont support 
} 


} catch (UnsupportedOperationException) {} 


If the menu Component doesn’t support the 
operation, we just throw away the exception and 
ignore it. 


In general we agree; try/catch is meant for error handling, 
not program logic. What are our other options? We could 
have checked the runtime type of the menu component with 
instanceof to make sure it’s a Menultem before making the 
call to isVegetarian(). But in the process we’d lose ¢ransparency 
because we wouldn’t be treating Menus and Menultems 
uniformly. 


We could also change isVegetarian() in the Menus so that it 
returns false. This provides a simple solution and we keep our 
transparency. 


In our solution we are going for clarity: we really want to 
communicate that this is an unsupported operation on the 
Menu (which is different than saying is Vegetarian() 1s false). It 
also allows for someone to come along and actually implement 
a reasonable isVegetarian() method for Menu and have it work 
with the existing code. 


That’s our story and we’re stickin’ to it. 
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interview with composite 


Patterns Exposed 


This week’s interview: 


HeadFirst: We’re here tonight speaking with the 
Composite Pattern. Why don’t you tell us a little about 
yourself, Composite? 


Composite: Sure... I’m the pattern to use when you 
have collections of objects with whole-part relationships 
and you want to be able to treat those objects uniformly. 


HeadFirst: Okay, let’s dive right in here... what do you 
mean by whole-part relationships? 


Composite: Imagine a graphical user interface; there 
you'll often find a top level component like a Frame or 
a Panel, containing other components, like menus, text 
panes, scrollbars and buttons. So your GUI consists 

of several parts, but when you display it, you generally 
think of it as a whole. You tell the top level component 
to display, and count on that component to display all 
its parts. We call the components that contain other 
components, composite objects, and components that 
don’t contain other components, leaf objects. 


HeadFirst: Is that what you mean by treating the 
objects uniformly? Having common methods you can 
call on composites and leaves? 


Composite: Right. I can tell a composite object to 
display or a leaf object to display and they will do the 
right thing. The composite object will display by telling 
all its components to display. 


HeadFirst: That implies that every object has the same 
interface. What if you have objects in your composite 
that do different things? 


Composite: Well, in order for the composite to work 
transparently to the client, you must implement the same 
interface for all objects in the composite, otherwise, the 
client has to worry about which interface each object 

is implementing, which kind of defeats the purpose. 
Obviously that means that at times you'll have objects for 
which some of the method calls don’t make sense. 


HeadFirst: So how do you handle that? 


oe) 
J 


Unapter - 
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Composite: Well there’s a couple of ways to handle 

it; sometimes you can just do nothing, or return null or 
false — whatever makes sense in your application. Other 
times you'll want to be more proactive and throw an 
exception. Of course, then the client has to be willing to 
do a little work and make sure that the method call didn’t 
do something unexpected. 


HeadFirst: But if the client doesn’t know which kind 
of object they’re dealing with, how would they ever know 
which calls to make without checking the type? 


Composite: If you're a little creative you can structure 
your methods so that the default implementations do 
something that does make sense. For instance, if the 
client is calling getChild(), on the composite this makes 
sense. And it makes sense on a leaf too, if you think of 
the leaf as an object with no children. 


HeadFirst: Ah... smart. But, I’ve heard some clients 
are so worried about this issue, that they require separate 
interfaces for different objects so they aren’t allowed 

to make nonsensical method calls. Is that still the 
Composite Pattern? 


Composite: Yes. It’s a much safer version of the 
Composite Pattern, but it requires the client to check the 
type of every object before making a call so the object 
can be cast correctly. 


HeadFirst: ‘Tell us a little more about how these 
composite and leaf objects are structured. 


Composite: Usually it’s a tree structure, some kind of 
hierarchy. The root is the top level composite, and all its 
children are either composites or leaf nodes. 


HeadFirst: Do children ever point back up to their 
parents? 


Composite: Yes, a component can have a pointer to a 
parent to make traversal of the structure easier. And, if 
you have a reference to a child, and you need to delete it, 
you'll need to get the parent to remove the child. Having 
the parent reference makes that easier too. 


HeadFirst: There’s really quite a lot to consider in your 
implementation. Are there other issues we should think 
about when implementing the Composite Pattern? 


Composite: Actually there are... one is the ordering 

of children. What if you have a composite that needs to 
keep its children in a particular order? Then you'll need 
a more sophisticated management scheme for adding and 
removing children, and you'll have to be careful about 
how you traverse the hierarchy. 


HeadFirst: A good point I hadn’t thought of. 
Composite: And did you think about caching? 
HeadFirst: Caching? 


Composite: Yeah, caching. Sometimes, if the 
composite structure 1s complex or expensive to traverse, 
it’s helpful to implement caching of the composite nodes. 
For instance, if you are constantly traversing a composite 
and all its children to compute some result, you could 
implement a cache that stores the result temporarily to 
save traversals. 


HeadFirst: Well, there’s a lot more to the Composite 
Patterns than I ever would have guessed. Before we 
wrap this up, one more question: What do you consider 
your greatest strength? 


Composite: I think I’d definitely have to say 
simplifying life for my clients. My clients don’t have to 
worry about whether they’re dealing with a composite 
object or a leaf object, so they don’t have to write if 
statements everywhere to make sure they’re calling the 
right methods on the right objects. Often, they can make 
one method call and execute an operation over an entire 
structure. 


HeadFirst: That does sound like an important benefit. 
There’s no doubt you’re a useful pattern to have around 
for collecting and managing objects. And, with that, 
we’re out of time... Thanks so much for joining us and 
come back soon for another Patterns Exposed. 
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RR It’s that time again... 
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Across 

1. User interface packages often use this pattern 
for their components. 

3. Collection and Iterator are in this package 
5. We encapsulated this. 

6. A separate object that can traverse a 
collection. 

10. Merged with the Diner. 

12. Has no children. 

13. Name of principle that states only one 
responsibility per class. 

14. Third company acquired. 

15. A class should have only one reason to do 
this. 

16. This class indirectly supports Iterator. 

17. This menu caused us to change our entire 
implementation. 


Chapter 9 


PT tT ET 


pt ET TE 
pT 


15 


PET 
Pi tc | ty 


Down 

1. A composite holds this. 

2. We java-enabled her. 

4. We deleted PancakeHouseMenulterator 
because this class already provides an iterator. 
5. The Iterator Pattern decouples the client from 
the aggregates . 
7. Compositelterator used a lot of this. 

8. lterators are usually created using this 
pattern. 

9. A component can be a composite or this. 

11. Hashtable and ArrayList both implement this 
interface. 
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+ 
WUuUS BOAES WHAT? 


Match each pattern with its description: 


Pattern Description 


Clients treat collections of 
Strategy objects and individual objects 
uniformly 


Provides a way te traverse a 
collection of objects without 
exposing the collection’s 
implementation 


Adapter 


Iterator Simplifies the interface of a 


group of classes 


ee Changes the interface of one 
or more classes 


Allows a group of objects to 
be notified when some state 
changes 


Encapsulates interchangeable 
behaviors and uses delegation te 
decide which one te use 
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Tools for your Design Toolbox 


Two new patterns for your toolbox -— two great ways 
to deal with collections of objects. 
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safety with your needs. 


An Iterator allows access to an 
aggregate’s elements without 
exposing its internal structure. 


An Iterator takes the job of 
iterating over an aggregate 
and encapsulates it in another 
object. 


When using an Iterator, we 
relieve the aggregate of the 
responsibility of supporting 

operations for traversing its 
data. 


An Iterator provides a common 
interface for traversing the 
items of an aggregate, allowing 
you to use polymorphism when 
writing code that makes use of 
the items of the aggregate. 


We should strive to assign 
only one responsibility to each 
class. 


The Composite Pattern 
provides a structure to hold 
both individual objects and 
composites. 


The Composite Pattern allows 
clients to treat composites and 
individual objects uniformly. 


A Component is any object 
in a Composite structure. 
Components may be other 
composites or leaf nodes. 


There are many design 
tradeoffs in implementing 
Composite. You need to 
balance transparency and 
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SEB Exereise solutions 


G harpen our pencil 
al y 


Based on our implementation of printMenu(), which of the following apply? 


(WA. We are coding to the &D. The Waitress needs to know how each 
PancakeHouseMenu and DinerMenu menu represents its internal collection of 
concrete implementations, not to an menu items is implemented, this violates 
interface. encapsulation. 


(J B. The Waitress doesn’t implement the WE. We have duplicate code: the printMenu 
p p. Pp 
ava Waitress API and so isn’t adherin: method needs two separate loo 
g p P 
to a standard. implementations to iterate over the two 
xy C different kinds of menus. And if we 


If we decided to switch fi sing : . 
es ee added a third menu, we might have to 
DinerMenu to another type of menu 
add yet another loop. 


that implemented its list of menu items 

with a Hashtable, we’d have to modify . The implementation isn’t based on 

a lot of code in the Waitress. MXML (Menu XML) and so isn’t as 
interoperable as it should be. 


G harpen your pencil 


ON Before turning the page, quickly jot down the three things we have 
to do to this code to fit it into our framework: 


implement the Menu interface 
2. get vid of getltems() 


3, add ereatelterator() and return an [terator that can step through the Hashtable values 
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Code Magnets Solution 


The unscrambled “Alternating” DinerMenu Iterator 


import java.util.Iterator; 
import java.util.Calendar; 


public class AlternatingDinerMenulIterator 


MenulItem[] items; 


implemen ts Iter a tor 
: posi tion; 


public AlternatingDinerMenuIterator (MenuItem[] items) 


this.items = items; 
Calendar rightNow = Calendar. getInstance(); 
position = rightNow. get (Calendar. DAY _OF WEEK) % 2; 


public boolean hasNext ( 


if (position >= items. length || items[position] == null) { 
return false; 
} else { 


return true; 


Public Object next() { 


Menultem menultem = items[position]; 
position = position + 2; 
return menultem; 


Notice that this Iterator 
implementation does not 
public void remove() { et vnovel) 
throw new UnsupportedOperationExcept ion ( 


“Alternating Diner Menu Iterator does not support remove ()”); 
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3 a 
we DOES WaT? 


Match each pattern with its description: 


Pattern Description 


Clients treat collections of 
State objects and individual objects 
uniformly 


Provides a Way to traverse a 
collection of objects without 
exposing the collection’s 
implementation 


Adapter 


Iterator : ae 
ae Simplifies the interface of a 


group of classes 


Facade Changes the interface of one 
or more classes 


Allows a group of objects to 
be notified when some state 
changes 


Composite 


Allows an object to change 
its behavior when some state 
changes 


Observer 


crossword puzzle solution 


SEB Exercise solutions 
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10 the State Pattern 


a 
+ The State of Things * 


I thought things in Objectville 
were going to be so easy, but now 
every time I turn around there's 
another change request coming in. 
I'm to the breaking point! Oh, maybe 
I should have been going to Betty's 
Wednesday night patterns group all 
along. I'm in such a state! 


A little known fact: the Strategy and State Patterns were twins 
separated at birth. As you know, the Strategy Pattern went on to create a wildly 
successful business around interchangeable algorithms. State, however, took the perhaps 
more noble path of helping objects to control their behavior by changing their internal 
state. He’s often overheard telling his object clients, “Just repeat after me: I’m good 


enough, I’m smart enough, and doggonit...” 


this is a new chapter 385 


meet mighty gumball 


va 
Jaw Breakers 


Java toasters are so “90s. ‘Today people are building Java into 
real devices, like gumball machines. That’s right, gumball 
machines have gone high tech; the major manufacturers have 


found that by putting CPUs into their machines, they can rat's theiv story - we . 
increase sales, monitor inventory over the network and measure see aust got pored with € : 
customer satisfaction more accurately. aid an Lethnolody and neede 
Le gaway make their Jors 
But these manufacturers are gumball machine experts, not ig . extitind 
mol 


software developers, and they’ve asked for your help: 


mball dehing tontroller needs 


Here's the way we Brink thes af plement this in Java *or us! We 


ve hop ou Can im 
ie ei Tina in the future, so Ae need to keep 
Mighty Gumball, Ine. rn design as Llexible and maintainable as possible: 
OP Ener Haren | = Mighty Gumball Engineers 
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Cubicle Conversation 


Let's take a look 
at this diagram and see 

what the Mighty Gumball 
guys want... 


Anne: This diagram looks like a state diagram. 
Joe: Right, each of those circles is a state... 
Anne: ... and each of the arrows is a state transition. 


Frank: Slow down, you two, it’s been too long since I studied state diagrams. 
Can you remind me what they’re all about? 


Anne: Sure, Frank. Look at the circles; those are states. “No Quarter” is 
probably the starting state for the gumball machine because it’s just sitting 
a Anne there waiting for you to put your quarter in. All states are just different 

vee Frank configurations of the machine that behave in a certain way and need some 


action to take them to another state. 


Joe: Right. See, to go to another state, you need to do something like put a quarter in the machine. See the arrow 
g. gs »y g Pp q 
from “No Quarter” to “Has Quarter?” 


Frank: Yes... 


Joe: That just means that if the gumball machine is in the “No Quarter” state and you put a quarter in, it will 
change to the “Has Quarter” state. That’s the state transition. 


Frank: Oh, I sce! And if I’m in the “Has Quarter” state, I can turn the crank and change to the “Gumball Sold” 
state, or eject the quarter and change back to the “No Quarter” state. 


Anne: You got it! 


Frank: This doesn’t look too bad then. We’ve obviously got four states, and I think we also have four actions: “inserts 
ys , 

quarter,” “ejects quarter,” “turns crank” and “dispense.” But... when we dispense, we test for zero or more gumballs 

in the “Gumball Sold” state, and then either go to the “Out of Gumballs” state or the “No Quarter” state. So we 


actually have five transitions from one state to another. 


Anne: That test for zero or more gumballs also implies we’ve got to keep track of the number of gumballs too. Any 
time the machine gives you a gumball, it might be the last one, and if it is, we need to transition to the “Out of 
Gumballs” state. 


Joe: Also, don’t forget that you could do nonsensical things, like try to eject the quarter when the gumball machine 
is in the “No Quarter” state, or insert two quarters. 


Frank: Oh, I didn’t think of that; we’ll have to take care of those too. 


Joe: For every possible action we’ll just have to check to see which state we’re in and act appropriately. We can do 
this! Let’s start mapping the state diagram to code... 


review of state machines 


State machines 101 


How are we going to get from that state diagram to actual code? Here’s a quick 
introduction to implementing state machines: 


e First, gather up your states: 


Guero 
cad 
vk 
ay 


(2) Next, create an instance variable to hold the current state, and define values for each of the states: 


Here are the states — four in total. 


Let's just tall “Out of Gumballs” 
“Cold Out” Lor short. “ 


final static int SOLD OUT = 0; 
final static int NO_ QUARTER = 1; 
final static int HAS QUARTER = 2; 
final static int SOLD = 3; 


Here's each state represented 
as a unique integer... 


and here’s an instance variable that holds the 


int state = SOLD OUT; ae current state. We'll go ahead and set it to 


“Cold Out” since the machine will be unfilled when 
it’s first taken out of its box and turned on. 


3 ) Now we gather up all the actions that can happen in the system: 
These actions are 
. the gumball machine $ 
inserts quarter turns crank we, interface — the things 
ejects quarter you Can do with it. 
dispense 
i Dispense is more of an internal 
Looking at the diagram, invoking, any of these attion the machine invokes on itself. 


actions causes a state transition. 
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4) Now we create a class that acts as the state machine. For each action, 
we create a method that uses conditional statements to determine 
what behavior is appropriate in each state. For instance, for the insert 
quarter action, we might write a method like this: 


public void insertQuarter() { 
if (state == HAS QUARTER) { 
SK Each possible 
System.out.printlin(“You can’t insert another quarter”); state is checked 
with a Conditional 
} else if (state == SOLD OUT) { a statement... 


System.out.println(“You can’t insert a quarter, the machine is/Sold out”); 
} else if (state == SOLD) { 
System.out.println(“Please wait, we’re already giving you a gumball”); 


} else if (state == NO QUARTER) { 


state = HAS QUARTER; 
System.out.printin(“You inserted a quarter”); 


| and exhibits the appropriate ; 
| behavior Lor each possi es 


but can also transition to other 
states, just as depicted in the diagram. 


Here we're talking 
about a common technique: 
modeling state within an object 
by creating an instance variable to hold 
the state values and writing conditional 
code within our methods to handle 
the various states. 


With that quick review, let’s go implement the Gumball Machine! 
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implement the gumbal! machine 


Writing the code 


It’s time to implement the Gumball Machine. We know we’re going to have an instance 
variable that holds the current state. From there, we just need to handle all the actions, 
behaviors and state transitions that can happen. For actions, we need to implement inserting 
a quarter, removing a quarter, turning the crank and dispensing a gumball; we also have the 
empty gumball condition to implement as well. 


3 m. h the 
Here are the four states: ore - one 
states in Mighty Gumball s state a1a9) 
ee ee ¢ Here's the instante variable that is going to 
keep track of the current state were in. 
final static int NO-OUARTER =| We start in the SOLD_OUT state. 
final static int NO QUARTER : 


final static int HAS QUARTE 
final static int SOLD = 3; 


We have a second instance variable that 
keeps track of the number of gumballs in 
sdegieed & Shu Gute the machine. 


int count = 0; 
The Constructor takes an initial inventory 
public GumballMachine(int count) { of gumballs. If the inventory isn't zero, 
this.count = count; the machine enters state NO QUARTER, 


if (count > 0) { 


meaning it is waiting for someone to 
state = NO QUARTER; 


insert a quarter, otherwise it stays in 


} the SOLD_OUT state. 


Now we start implementing 


the actions as methods When a quarter is inserted, if... 


 — a quarter is already inserted 
public void insertQuarter() { 


we tell the customer; 


if (state == HAS QUARTER) { 
System.out.printin(“You can’t insert another quarter”); otherwise we accept the 

| ates te Stee. == Ne ued Pe i quarter and transition to the 
state = HAS QUARTER; 


HAS QUARTER state. 


System.out.printlin(“You inserted a quarter”); 


} else if (state == SOLD OUT) { 
System.out.printin(“You can’t insert a quarter, the machine is sold out”); 
} else if (state == SOLD) { 


System.out.printlin(“Please wait, we’re already giving you a gumball”); 
} 
| = d if the machine is sold 
If the customer just bought a and i ¢ ei aaa 
gumball he needs to wait until the out, we reject the 
Lyansattion is Complete before 
inserting another quarter. 
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KY) Now, if the customer tries to remove the quarter... 


\f there is a quarter, we 


public void ejectQuarter() { veturn it and go back to the 
if (state == HAS QUARTER) { | NO QUARTER state. 
System.out.printlin (“Quarter returned”) ; = 
state = NO QUARTER; iio Otherwise, if there isn't 
} else if (state == NO QUARTER) { one we can't give it back. 
System.out.printin(“You haven’t inserted a quarter”); 
} else if (state == SOLD) { 
System.out.printlin(“Sorry, you already turned the crank”); 
} else if (state == SOLD OUT) { 
System.out.printin(“You can’t eject, you haven’t inserted a quarter yet”); 
} se You ean't eject if the machine is sold If the customer just 
} out, it doesn’t accept quarters! turned i trank, we can't 
ive a retund; he alread 
( The customer tries to turn the trank... i. te sia Wl Y 
subi: weld cuenceenk J Someone's trying to cheat the machine. 
if (state == SOLD) { 
System.out.printin(“Turning twice doesn’t get you another gumball!”) ; We need a 
} else if (state == NO QUARTER) { quarter first. 
System.out.printlin(“You turned but there’s no quarter”); 
} else if (state == SOLD OUT) { 


; 3 
System.out.println(“You turned, but there are no gumballs”); We can't deliver 

} else if (state == HAS QUARTER) { gumballs; there 
System.out.printlin(“You turned...”); aire none. 
state = SOLD; 
dispense (); 


} ‘<< Called to dispense a gumball. 


Success! They get a gumball. Change 
the state to SOLD and call the 


} machine's dispense() method. 
Were in the 
public void dispense() { xv SOLD state) 9ve 
if (state == SOLD) { Sem a gumnball: 


System.out.printlin(“A gumball comes rolling out the slot”); 
count = count - 1; 
if (count == 0) { 


Here's where We handle o 
«4 of oumballs” condition’ 
System.out.println(“Oops, out of gumballs!”); out oF 9} last one, we SE 
state = SOLD OUT; this was the tate te SOLD_ 
} else { the machine S °"" eve back 40 
state = NO QUARTER; QUT; otherwise, were 
} not having a arte 
} else if (state == NO QUARTER) { 
System.out.println (“You need to pay first”); —, 
} else if (state == SOLD OUT) { — 
System.out.println(“No gumball dispensed”) ; ee 
} else if (state == HAS QUARTER) { 
System.out.println(“No gumball dispensed”) ; 


None of these should 
ever happen, but if they 
do, we give ‘em an error, 


not a gumball. 


} 


// other methods here like toString() and refill () 
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test the gumbal! machine 


In-house testing 


That feels like a nice solid design using a well-thought out methodology, doesn’t 
it? Let’s do a little in-house testing before we hand it off to Mighty Gumball to 
be loaded into their actual gumball machines. Here’s our test harness: 


Load it up with 
public class GumballMachineTestDrive { - five gumballs total. 
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public static void main(String[] args) { 


GumballMachine gumballMachine = new GumballMachine (5); 
S____ Print out the state of the machine. ee a 
System. out.printlin(gumballMachine) ; 
— Throw a quarter in... , ae 
gumballMachine.insertQuarter(); ; 
gimbal Maekine. cernerank iis a Turn the érank; we should get our gumball. 


System. out.printin(gumballMachine) ; \ Print out the state of the machine, again. 2 
(a . 
gumballMachine.insertQuarter(); ee ° ge ” _—— 
gumballMachine.ejectQuarter(); Ask for it back. 
lballMachi me Cc k();7 
gumballMachine. turnCrank () iti Turn the erank; we shouldn't get our gumball. 
System.out.println(gumballMachine) ; Pe Print out the state of the machine, again. 


=> _ Throwa quarter in... 


gumballMachine.insertQuarter (); eo 

gumballMachine.turnCrank(); << io sr alga get our gumball 
carne an Sey Oi S—_ Turn the crank; we should get our gumball 
gumballMachine. turnCran ; oe 
cunba Lineohine,ereendusekent) | —__ Ask for a quarter back we didn't put in. 


System. out.print1n(gumballMachine) ; X\_____ Print out the state of the machine, again. ee 


ae <— Throw TWO quarters in... 
gumballMachine.insertQuarter (); ‘Tarn the eae wesheld get ge gumball. 


gumballMachine.insertQuarter(); =s__ SS 
gumballMachine.turnCrank(); : 
gumballMachine. insertQuarter (); Sa Now for the stress testing... © 


gumballMachine.turnCrank () ; 
gumballMachine.insertQuarter(); 


umballMachine.turnCrank(); & 
e . Print that machine state one more time. ee 


System. out.printlin(gumballMachine) ; 
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| File Edit Window Help mightygumballcom 
Sjava GumballMachineTestDrive 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 5 gumballs 

Machine is waiting for quarter 


You inserted a quarter 
You turned... 
A gumball comes rolling out the slot 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 4 gumballs 

Machine is waiting for quarter 


You inserted a quate 
Quarter returne 
You turned but there’s no quarter 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 4 gumballs 

Machine is waiting for quarter 


You inserted a quarter 
You turned... 
A gumball comes rolling out the slot 


You inserted a quarter 

You turned... 

A gumball comes rolling out the slot 
You haven’t inserted a quarter 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 2 gumballs 

Machine is waiting for quarter 


You inserted a quarter 

You can’t insert another quarter 

You turned... 

A gumball comes rolling out the slot 

You inserted a quarter 

You turned... 

A gumball comes rolling out the slot 

Oops, out of gumballs! ; ; 

You can’t insert a quarter, the machine is sold out 
You turned, but there are no gumballs 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 0 gumballs 

Machine is sold out 
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gumball buying game 


You knew it was coming... a change request! 


Mighty Gumball, Inc. has loaded your code into their new- 
est machine and their quality assurance experts are putting 
it through its paces. So far, everything’s looking great from 
their perspective. 


In fact, things have gone so smoothly they’d like to take 
things to the next level... 


We think that by turning 
“gumball buying” into a game we 
can significantly increase our 
sales. We're going to put one of 
these stickers on every machine. 
We're so glad we've got Java 
in the machines because this is 
going to be easy, right? 


10% of the Lime, 


CEO, Mighty hen the erank 
Gumball, Ine is turned ie two 
tomer 9€ 
aces ov cpnball instead 
umarroy: 


of one- 


Gumballs _ 7 
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Design Puzzle 


Draw a state diagram for a Gumball Machine that handles the 1 in 10 
contest. In this contest, 10% of the time the Sold state leads to two 
balls being released, not one. Check your answer with ours (at the 
end of the chapter) to make sure we agree before you go further... 


Use Mighty Gumball’s stationary to draw your state diagram. 


youarehere > 395 


things get messy 


The messy STATE of things... 


Just because you’ve written your gumball machine using a well-thought out methodology doesn’t 
mean it’s going to be easy to extend. In fact, when you go back and look at your code and think 
about what you'll have to do to modify it, well... 


First, you'd have to add a new WINNER state here. 


final static int SOLD OUT = 0; ; 
That isnt too bad... 


final static int NO QUARTER = 1; 
final static int HAS QUARTER = 2; 
final static int SOLD = 3; 


public void insertQuarter() { 
// insert quarter code here 


~ .. but then, you'd have to add a new tonditional in 


public void ejectQuarter() { ee every single method to handle the WINNER state; 
// eject quarter code here ae that’s a lot of tode to modify. 

} we 

public void turnCrank() { 
// turn crank code here 

} turnCrank() will get especially messy, because 

\y you'd have to add code to check to see whether 

public void dispense() { youve got a WINNER and then switch to either 

a the WINNER state or the SOLD state. 


G harpen our pencil 
a y 


Which of the following describe the state of our implementation? 
(Choose all that apply.) 


1 A. This code certainly isn’t adhering to the [J D. State transitions aren’t explicit; they 
Open Closed Principle. are buried in the middle of a bunch of 


LJ B. This code would make a FORTRAN 
programmer proud. LJ E. We haven’t encapsulated anything that 


conditional statements. 


: ne . varies here. 
LI C. This design isn’t even very object 


oriented. ’ Further additions are likely to cause bugs 
in working code. 
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Okay, this isn't good. I think 
our first version was great, but 
it isn't going to hold up over time as Mighty 
Gumball keeps asking for new behavior. The 
rate of bugs is just going to make us look 
bad, not to mention that CEO will drive 
us crazy. 


Joe: You’re right about that! We need to refactor this code so that it’s easy 
to maintain and modify. 


Anne: We really should try to localize the behavior for cach state so that if 
we make changes to one state, we don’t run the risk of messing up the other 
code. 


Joe: Right; in other words, follow that ol’ “encapsulate what varies” 
principle. 


Anne: Exactly. 


Joe: If we put each state’s behavior in its own class, then every state just 
implements its own actions. 


Anne: Right. And maybe the Gumball Machine can just delegate to the 
state object that represents the current state. 


Joe: Ah, you’re good: favor composition... more principles at work. 


Anne: Cute. Well, ’m not 100% sure how this is going to work, but I think 
we’re on to something. 


Joe: I wonder if this will make it easier to add new states? 


Anne: I think so... We’ll still have to change code, but the changes will be 
much more limited in scope because adding a new state will mean we just 
have to add a new class and maybe change a few transitions here and there. 


Joe: I like the sound of that. Let’s start hashing out this new design! 


| 
y141 are hera 
you are nere 


> 
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a new State design 


The new design 


It looks like we’ve got a new plan: instead of maintaining our existing code, we’re going to 
rework it to encapsulate state objects in their own classes and then delegate to the current 
state when an action occurs. 


We’re following our design principles here, so we should end up with a design that is easier to 
maintain down the road. Here’s how we’re going to do it: 


1) First, we’re going to define a State interface that 
contains a method for every action in the Gumball 
Machine. 


(2) Then we’re going to implement a State class for 
every state of the machine. These classes will be 
responsible for the behavior of the machine when it 
is in the corresponding state. 


(3) Finally, we’re going to get rid of all of our conditional 
code and instead delegate to the state class to do 
the work for us. 


Not only are we following design principles, as you'll see, we’re actually implementing the 
State Pattern. But we’ll get to all the official State Pattern stuff after we rework our code... 


Now we're going to 
put all the behavior of a 
state into one class. That way, 
we're localizing the behavior and 
making things a lot easier to 
change and understand. 
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Defining the State interfaces and classes 


First let’s create an interface for State, which all our states implement: 


The methods map directly to 


; ; Il states. 
Heve’s the interface for all state re wil these ane the 


actions that could happen to the Gumball Mac 
same methods as in the previous tode). 


. ; <<interface>> 
Then take each state in our design State 
and encapsulate it in a class that oe 
. . eyectQuarier( 
implements the State interface. incl 
dispense() 


NON vs, 
To figure out what states a 2 
we need, we look at our SoldState SoldOutState NoQuarterState HasQuarterState 
previous code... insertQuarter() insertQuarter() insertQuarter() insertQuarter() 
ejectQuarter() ejectQuarter() ejectQuarter() ejectQuarter() 
turnCrank() turnCrank() turnCrank() turnCrank() 
dispense() dispense() dispense() dispense() 


KA TA 


.. and we map each state 
diveetly to a class. 


public class GumballMachine { 


final static int SOLD OUT = 
final static int NO QUARTER : 
final static int HAS QUARTER = 2; 
final static int SOLD = 3; 


Don't forget, we need a new “winner” state too 
cae aaa that implements the state interface. We'll come 
pees back to this after we veimplement the first 


version of the Gumball Machine. 


WinnerState 
insertQuarter() 
ejectQuarter() 
turnCrank() 
dispense() 
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what are all the states? 


G harpen your pencil 
IN To implement our states, we first need to specify the behavior of the classes 
when each action is called. Annotate the diagram below with the behavior of 
each action in each class; we've already filled in a few for you. 


Go to HasQuarterState 
« ) NoQuarterStat 
Tell the customer, “You haven't inserted a quarter.” ee —_ 


ejectQuarter() 
turnCrank() 
dispense() 


HasQuarterState 
insertQuarter() 
ejectQuarter() 


Go to SoldState ee) turnCrank() 


dispense() 


Tell the customer, “Please wait, we're already giving You 2 gumball.” 


SoldState 
insertQuarter() 
ejectQuarter() 
turnCrank() 
Dispense one gumball. Check number of gumballs; if > O, go eee 
to NoQuarterState, otherwise, go to SoldOutState nemaniilll 


SoldOutState 
insertQuarter() 
ejectQuarter() 


eee turnCrank() 


dispense() 


Tell the customer, “There are no gumballs.” 


WinnerState 
insertQuarter() 
ejectQuarter() 
turnCrank() 
dispense() 


Go ahead and fill this out even though we've implementing it later. 
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Implementing our State classes 


Time to implement a state: we know what behaviors we want; we just need to get it down in code. We’re going to 
closely follow the state machine code we wrote, but this time everything is broken out into different classes. 


Let’s start with the NoQuarterState: 


_ plement the State interface 
First, we need to aaa We get passed a reference to 

the Gumball Machine through the 
constructor. We're just going to 


stash this in an instanée variable. 


public class NoQuarterState implements State { 
GumballMachine gumballMachine; 
If someone inserts a quarter, 
we print a message saying the 
uarter was accepted and then 
change the machine's state 


public void insertQuarter() { Lo the HasQuarterState. 


System.out.printlin(“You inserted a quarter”); 
gumballMachine.setState (gumballMachine.getHasQuarterState()); 


public NoQuarterState(GumballMachine gumballMachine) { 
this.gumballMachine = gumballMachine; 


You'll see how these 


Fe work in just a see... 


public void ejectQuarter() { 

System.out.println(“You haven’t inserted a quarter”); Vai tar’t get money 
back if You never gave 
public void turnCrank() { it to us! 


System.out.printin(“You turned, but there’s no quarter”); 


i And, you tan’t get a gumball 


: ? 
public void dispense() { if is don t pay us. 
System.out.printin(“You need to pay first”); ) . 
—_ We ¢an't be dispensing 


. gumballs without payment. 


} 


What we're doing is 
implementing the behaviors 
that are appropriate for the 
state we're in. In some cases, this 
behavior includes moving the 
Gumball Machine to a new state. 
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State objects in the gumbal!l machine 


Reworking the Gumball Machine 


Before we finish the State classes, we're going to rework the Gumball Machine - that way 
you can see how it all fits together. We'll start with the state-related instance variables 
and switch the code from using integers to using state objects: 


public class GumballMachine { 


final static int SOLD OUT = 0; «ewe update the 
final static int NO QUARTER = 1; In the ee tee than 
final static int HAS QUARTER = 2; code to use mere The tode is quite 
final static int SOLD = 3; the statie cia e class we have 
- at in on 
similar, exceP sepbe: 
int state e other bje 


SOLD_OUT; 


integers and in th 
0; 


int count = 


Old tode 


public class GumballMachine { 


New code 


State 
State 
State 
State 


State 


int count 


soldOutState; 
noQuarterState; 
hasQuarterState; 
soldState; 


state soldOutState; 


All the State objects are created 
and assigned in the constructor. 


This now holds a 
State object, not 
an integer: 
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Now, let’s look at the complete GumballMachine class... 


public class GumballMachine { 


State soldOutState; 


State state soldOutState; 


int count = 0; 


public GumballMachine (int numberGumballs) : ‘able 
soldOutState = new SoldOutState (this) ; in an instance var 
noQuarterState = new NoQuarterState (this) ; —_ I also eveates the State 
hasQuarterState = new HasQuarterState (this) ; 
soldState = new SoldState (this); 


this.count = numberGumballs; 


if (numberGumballs > 0) { 
state = noQuarterState; 
} 
} 


public void insertQuarter() { 
state.insertQuarter(); 


} 


public void ejectQuarter() { 
state.ejectQuarter(); 


} 


public void turnCrank() { 
state.turnCrank(); 
state.dispense (); 


} 


void setState(State state) { 
this.state = state; 


} 


void releaseBall() { 


Here are all the States again-- 


a and the State instance variable. 


State noQuarterState; 
State hasQuarterState; 
State soldState; 


The count instante variable holds 


the count of gumballs — initially the 
machine is empty. 


takes the initial 
i, Our baa and stores it 


{ number oF 9M 
) 


instances, one each. 


If there are more than O 


a _ gumballs we set the state to the 
NoQuarterState. 


~. These are 
Now for te actions ow: 


; ment Wi 
VERY EASY to imleme tate. 


so 
a. jpst delegate he curren 


Note that we don't need an 
Betion method for dispense() in 
GumballMachine because it’s just an 


| —— internal action; a user can't ask the 
machine to dispense directly. But we 


do ¢all dispense() on the State object 
from the turnCrank() method. 


This method allows other objects (like 
aie Ceska siete) to branctonthe 
machine to a different state. 


System.out.printlin(“A gumball comes rolling out the slot...”); 


if (count != 0) { 
count = count - 1; 


} 


The machine supports a veleaseBall() 
helper method that releases the ball and 
decrements the count instance variable. 


// More methods here including getters for each State... 


This ineludes methods like getNoQuarterStatel) for getting each 
state object, and getCount() for getting the gumball count. 
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more states for the gumball machine 


Implementing more states 


Now that you’re starting to get a feel for how the Gumball Machine and the states 
fit together, let’s implement the HasQuarterState and the SoldState classes... 


te is instantiated 


When the sta the 
e pass ita veferente to <t 
Ww 6 This is ¥ 
achine- : 
public class HasQuarterState implements State { Guna ee the machine to a 
GumballMachine gumballMachine; to trans! stake 
different ; 
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public HasQuarterState(GumballMachine gumballMachine) { 


this.gumballMachine = gumballMachine; 
} 


An ina? rropriate 


; {his 

public void insertQuarter() { attion tor 
System.out.printlin(“You can’t insert another quarter”) ; state. 

} ) 

Return the customer S 

public void ejectQuarter() { — quarter and 
System.out.println (“Quarter returned”) ; transition back to the 
gumballMachine.setState (gumballMachine.getNoQuarterState()); NoQuarterState. 

} 

public void turnCrank() { When the erank is 
System.out.printin(“You turned...”); aiiienan turned we transition 


gumballMachine.setState (gumballMachine.getSoldState()); 


the machine to the 


SoldState state by 
public void dispense() { ealling its setStatel) 
System.out.println(“No gumball dispensed”) ; method and passing : 
the SoldState ob ject. 
fe The SoldState object 
imagrroneay’ is retrieved by the 
action or this wetSaldState ) 
state getter method 
(there is one of these 
getter methods for 
each state). 
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Now, let’s check out the SoldState class... Here are all the 


inapRProRerare 
, ‘ actions Tor this 
public class SoldState implements State { L 
//constructor and instance variables here state 
public void insertQuarter() { 
System.out.println(“Please wait, we’re already giving you a gumball”); 
} 
public void ejectQuarter() { 
System.out.printlin(“Sorry, you already turned the crank”); 
} 
public void turnCrank() { 
System.out.printlin(“Turning twice doesn’t get you another gumball!”); 
} 
public void dispense() { 
gumballMachine.releaseBall (); 
if (gumballMachine.getCount() > 0) { 
gumballMachine.setState (gumballMachinke.getNoQuarterState()); 
} else f{ 
System.out.println(“Oops, out of gymballs!”); 
gumballMachine.setState (gumballM@chine.getSoldoOutState()); 
} 
} 
} 
e . ine what 
And here s where th ctate whith Then we ask the math ther 
beains ) the Sold ; nt is, and et 
eal work be Weve " gid. So ae umball cou LerState 
‘ ears the customer fi +e cition to the NoBuae'# 
m e sition 
as! an : 
we first need %2 mba the ColdOutState 
«» to release 9M or 
machine 


POWER 


Look back at the GumballMachine implementation. If the crank is turned and not successful (say 


the customer didn’t insert a quarter first), we call dispense anyway, even though it’s unnecessary. 
How might you fix this? 
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your turn to 


We have one remaining class we haven’t implemented: SoldOutState. 
Why don’t you implement it? To do this, carefully think through how 
the Gumball Machine should behave in each situation. Check your 
answer before moving on... 


Ge sharpen your pencil 
ren yer p 


public class SoldOutState implements State 
GumballMachine gumballMachine; 


public SoldOutState(GumballMachine gumballMachine) { 


{ 


void insertQuarter () 


{ 


void ejectQuarter () 


{ 


void turnCrank () 


{ 


void dispense () 
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Let’s take a look at what we've done so far... 


For starters, you now have a Gumball Machine implementation that is structurally quite different from your 
first version, and yet functionally it ts exactly the same. By structurally changing the implemention you've: 


= Localized the behavior of each state into its own class. 
= Removed all the troublesome if statements that would have been difficult to maintain. 


= Closed each state for modification, and yet left the Gumball Machine open to extension by 
adding new state classes (and we'll do this in a second). 


=" Created a code base and class structure that maps much more closely to the Mighty Gumball 
diagram and is easier to read and understand. 


Now let’s look a little more at the functional aspect of what we did: 


Machine now holds an 


se wee cath State as —— Gumball Machine States 


instance 


current state 


The current state of the 


machine is always one o 
these class instances. 


Soldow' 
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state transitions 


When an action is talled, it is 
delegated to the current state. 


— turnCrank() 


turnCrank() 


In this case the turnCrank() 
method is being called when the 
machine is in the HasQuarter 
state, so as a result the machine 
transitions to the Sold state. 


Gumball Machine States 


Solgov" 


TRANSITION TO SOLD STATE al 


da 
My Sold state an 
sntal is dispensed 


dispense() 
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chine States 
Gumball Ma - = 
r) ) ....and then the 
Seg? machine will 
either go to 
the SoldOut 
or NoQuarter 


state depending 
on the number of 
gumballs remaining 
in the machine. 


sold out 


Soldov' 


& harpen our pencil 
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Gumball Machine States 
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Gumball Machine States 
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the state pattern 


Behind the Scenes: 
Self-Guided Tour 


Trace the steps of the Gumball Machine starting with the NoQuarter state. Also annotate the diagram with actions 
and output of the machine. For this exercise you can assume there are plenty of gumballs in the machine. 


2) 


os 


oY Uv 
“bain 


coy LY 
“bal | mo 


Gumball Machine States 
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Gumball Machine States 
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State pattern defined 


The State Pattern defined 


Yes, it’s true, we just implemented the State Pattern! So now, let’s take a look at what it’s all about: 


The State Pattern allows an object to alter its behavior 
when its internal state changes. The object will appear to 


change its class. 


The first part of this description makes a lot of sense, right? Because the pattern encapsulates state into 
separate classes and delegates to the object representing the current state, we know that behavior changes 
along with the internal state. The Gumball Machine provides a good example: when the gumball machine 
is in the NoQuarterState and you insert a quarter, you get different behavior (the machine accepts the 
quarter) than if you insert a quarter when it’s in the HasQuarterState (the machine rejects the quarter). 


What about the second part of the definition? What does it mean for an object to “appear to change its 
class?” Think about it from the perspective of a client: if an object you’re using can completely change its 
behavior, then it appears to you that the object is actually instantiated from another class. In reality, however, 
you know that we are using composition to give the appearance of a class change by simply referencing 
different state objects. 


Okay, now it’s time to check out the State Pattern class diagram: 


The State interface defines a Common 
interface for all contrete states; the 
states all implement the same interface, 
so they are interchangeable. 


The Context is the class that 
tan have a number of internal 
states. In our example, the 
GumballMachine is the Context. 


oa Context 
request() 


State 
handle() 


state.handle() ConcreteStateA ConcreteStateB ) 


ye handle() handle() Many Contrete 
tat, 


States are Possible. 
Whenever the request() is ee 


made on the Context ; 
is delegated bo the pa ContreteStates handle requests From the 


t hale Context. Each ConereteState provides its 
own implementation for a request: In this 
way, when the Context changes state, its 
behavior will change as well. 
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Wait a sec, 
from what I remember 
of the Strategy Pattern, 
this class diagram is 
EXACTLY the same. 


You've got a good eye! Yes, the class diagrams are essentially the 
same, but the two patterns differ in their zéent. 


With the State Pattern, we have a set of behaviors encapsulated in 
state objects; at any time the context is delegating to one of those 
states. Over time, the current state changes across the set of state 
objects to reflect the internal state of the context, so the context’s 
behavior changes over time as well. The client usually knows very 
little, if anything, about the state objects. 


With Strategy, the client usually specifies the strategy object that 
the context is composed with. Now, while the pattern provides the 
flexibility to change the strategy object at runtime, often there is a 
strategy object that is most appropriate for a context object. For 
instance, in Chapter |, some of our ducks were configured to fly 
with typical flying behavior (like mallard ducks), while others were 
configured with a fly behavior that kept them grounded (like rubber 
ducks and decoy ducks). 


In general, think of the Strategy Pattern as a flexible alternative to 
subclassing; if you use inheritance to define the behavior of a class, 
then you’re stuck with that behavior even if you need to change it. 
With Strategy you can change the behavior by composing with a 
different object. 


Think of the State Pattern as an alternative to putting lots of 
conditionals in your context; by encapsulating the behaviors within 
state objects, you can simply change the state object in context to 
change its behavior. 


q&a about the state 
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Q: In the GumballMachine, the states decide 
what the next state should be. Do the ConcreteStates 
always decide what state to go to next? 


: No, not always. The alternative is to let the Context 
decide on the flow of state transitions. 


As a general guideline, when the state transitions are fixed 
they are appropriate for putting in the Context; however, 
when the transitions are more dynamic, they are typically 
placed in the state classes themselves (for instance, in the 
GumballMachine the choice of the transition to NoQuarter or 
SoldOut depended on the runtime count of gumballs). 


The disadvantage of having state transitions in the state 
classes is that we create dependencies between the state 
classes. In our implementation of the GumballMachine 
we tried to minimize this by using getter methods on the 
Context, rather than hardcoding explicit concrete state 
classes. 


Notice that by making this decision, you are making a 
decision as to which classes are closed for modification 
— the Context or the state classes — as the system evolves. 


Q: Do clients ever interact directly with the 
states? 


A: No. The states are used by the Context to 
represent its internal state and behavior, so all requests 
to the states come from the Context. Clients don’t directly 
change the state of the Context. It is the Context’s job 

to oversee its state, and you don’t usually want a client 
changing the state of a Context without that Context’s 
knowledge. 


Q: If | have lots of instances of the Context in my 
application, is it possible to share the state objects 
across them? 


A: Yes, absolutely, and in fact this is a very common 
scenario. The only requirement is that your state objects do 
not keep their own internal state; otherwise, you'd need a 


Questions 


unique instance per context. 


To share your states, you'll typically assign each state to a 
static instance variable. If your state needs to make use of 
methods or instance variables in your Context, you'll also 
have to give it a reference to the Context in each handler() 
method. 


Q: It seems like using the State Pattern always 
increases the number of classes in our designs. Look 
how many more classes our GumballMachine had 
than the original design! 


A: You're right, by encapsulating state behavior 

into separate state classes, you'll always end up with 
more classes in your design. That’s often the price you 
pay for flexibility. Unless your code is some “one off” 
implementation you're going to throw away (yeah, right), 
consider building it with the additional classes and you'll 
probably thank yourself down the road. Note that often 
what is important is the number of classes that you expose 
to your clients, and there are ways to hide these extra 
classes from your clients (say, by declaring them package 
visible). 


Also, consider the alternative: if you have an application 
that has a lot of state and you decide not to use separate 
objects, you'll instead end up with very large, monolithic 
conditional statements. This makes your code hard to 
maintain and understand. By using objects, you make 
states explicit and reduce the effort needed to understand 
and maintain your code. 


Q: The State Pattern class diagram shows 
that State is an abstract class. But didn’t you use 
an interface in the implementation of the gumball 
machine's state? 


A: Yes. Given we had no common functionality to 

put into an abstract class, we went with an interface. In 
your own implementation, you might want to consider an 
abstract class. Doing so has the benefit of allowing you to 
add methods to the abstract class later, without breaking the 
concrete state implementations. 


the state pattern 


We still need to finish the Gumball 1 in 10 game 


Remember, we’re not done yet. We’ve got a game to implement; but now that we’ve got the State 
Pattern implemented, it should be a breeze. First, we need to add a state to the GumballMachine class: 


public class GumballMachine { 


State soldOutState; 


State noQuarterState; All you need to add here is the 
State hasQuarterState; new WinnerState and initialize 
State soldState; a “ n the constructor. 


State winnerState; 


State state 


= soldOutState; 
int count = 0; 


Don't forget you also have 


hod for 
i to add a getter met 
// methods here WernerState tox: 


Now let’s implement the WinnerState class itself, it’s remarkably similar to the SoldState class: 


public class WinnerState implements State { 


instance variables and constructor a 


// insertQuarter error messag 


// Just like SoldState- 


ither 90 
Here we release two gumballs and then ei 
be the NoQuarterState or the SoldOutState. 


// ejectQuarter error messag 


// turnCrank error message 


public void dispense() { 
System.out.println(“YOU’RE A WINNER! You get two gumballs for your quarter”); 
gumballMachine.releaseBall (); 
if (gumballMachine.getCount() == 0) { 
gumballMachine.setState (gumballMachine.getSoldOutState()); 
} else f{ 
gumballMachine.releaseBall (); aS As long as we 
if (gumballMachine.getCount() > 0) { have a second 
gumballMachine.setState (gumballMachine.getNoQuarterState()); gumball we 
} else { velease it. 
System.out.printlin(“Oops, out of gumballs!”); 
gumballMachine.setState (gumballMachine.getSoldoOutState()); 
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implementing the 7 in 10 game 
Finishing the game 


We've just got one more change to make: we need to implement the random 
chance game and add a transition to the WinnerState. We’re going to add both to 
the HasQuarterState since that is where the customer turns the crank: 


a First we add a 


public class HasQuarterState implements State { random number 
HOES OI RECURS Fee eer (System. currentTimeMillis()); generator to 6 
umba achine gumba achine; generate the |O7/ 


£ winnind,.- 
public HasQuarterState(GumballMachine gumballMachine) { chance © 9 


this.gumballMachine = gumballMachine; 


public void insertQuarter() { 
System.out.printin(“You can’t insert another quarter”); 


public void ejectQuarter() { 
System.out.printlin(“Quarter returned”) ; 


then we determine 
umballMachine.setState (gumballMachine.getNoQuarterState H : 
} A (g ca 0) if this customer won. 


public void turnCrank() { 
System.out.printin(“You turned...”); 
int winner = randomWinner.nextInt (10); 
if ((winner == 0) && (gumballMachine.getCount() > 1)) { 
gumballMachine.setState (gumballMachine.getWinnerState()); 


} else { 
gumballMachine.setState (gumballMachine.getSoldState()); ) 


; If they won, and there's 


enough gumballs left for 
public void dispense() { i oe ee tie ve 
System.out.println(“No gumball dispensed”) ; go to the WinnerState; 
; otherwise, we g0 to the 
} SoldState Gust like we 
always did). 


Wow, that was pretty simple to implement! We just added a new state to the GumballMachine 
and then implemented it. All we had to do from there was to implement our chance game and 
transition to the correct state. It looks like our new code strategy is paying off... 
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Demo for the CEO of Mighty Gumball, Inc. 


The CEO of Mighty Gumball has dropped by for a demo of your new gumball game code. Let’s 
hope those states are all in order! We’ll keep the demo short and sweet (the short attention span of 
CEOs is well documented), but hopefully long enough so that we’ll win at least once. 


asn t changed at all, 


: lly h 
This code really habit 


we just shortened 


Once, again, start with a gumball 
public class GumballMachineTestDrive { “a machine with 9 gumballs. 


public static void main(String[] args) { 
GumballMachine gumballMachine = new GumballMachine (5); 


System.out.printlin(gumballMachine) ; 


ine. i C—__ We want to get a winning state, 
gumballMachine.insertQuarter() ; oe just oe fate Unose 


quarters and turning the erank. We 
System.out.println(gumballMachine) ; print out the state of the gumball 
machine every so ten... 


gumballMachine.turnCrank () ; 


gumballMachine.insertQuarter(); 
gumballMachine.turnCrank () ; 
gumballMachine.insertQuarter(); 
gumballMachine.turnCrank (); 


System.out.printlin(gumballMachine) ; 


The whole engineering, team is waiting 
outside the tonference room to see i 


the new State Pattern—based design 
is 9019, to work! | 
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testing the gumbal! machine 


| | 
Yes! That rocks! File Edit Window Help Whenisagumballajawbreaker? 


Sjava GumballMachineTestDrive 

Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 5 gumballs 

Machine is waiting for quarter 


You inserted a quarter 

You turned... 

YOU’RE A WINNER! You get two gumballs for your quarter 
A gumball comes rolling out the slot... 

A gumball comes rolling out the slot... 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 3 gumballs 

Machine is waiting for quarter 


You inserted a quarter 
You turned... 
A gumball comes rolling out the slot... 
You inserted a quarter 
2 You turned... 
Gee, did we get lucky ov what! YOU'RE A WINNER! You get two gumballs for your quarter 
In our demo to the CEO, _ ede ® gumball comes rolling out the slot... 
ot onte, but twice! A gumball comes rolling out the slot... 
lil Oops, out of gumballs! 


Mighty Gumball, Inc. 

Java-enabled Standing Gumball Model #2004 
Inventory: 0 gumballs 

Machine is sold out 


% 


thereyare no, 
DumbQuestions 


Q: Why do we need the WinnerState? Couldn’t we just have the SoldState dispense two gumballs? 


A: That's a great question. SoldState and WinnerState are almost identical, except that WinnerState dispenses two 
gumballs instead of one. You certainly could put the code to dispense two gumballs into the SoldState. The downside 
is, of course, that now you've got TWO states represented in one State class: the state in which you're a winner, and the 
state in which you're not. So you are sacrificing clarity in your State class to reduce code duplication. Another thing to 
consider is the principle you learned in the previous chapter: One class, One responsibility. By putting the WinnerState 
responsibility into the SoldState, you've just given the SoldState TWO responsibilities. What happens when the 
promotion ends? Or the stakes of the contest change? So, it’s a tradeoff and comes down to a design decision. 
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Bravo! Great job, 
gang. Our sales are already going 
through the roof with the new game. 
You know, we also make soda machines, 
and I was thinking we could put one of 
those slot machine arms on the side and 
make that a game too. We've got four 
year olds gambling with the gumball 
machines; why stop there? 


Sanity check... 


Yes, the CEO of Mighty Gumball probably needs a sanity check, but that’s 
not what we’re talking about here. Let’s think through some aspects of the 
GumballMachine that we might want to shore up before we ship the gold version: 


= We've got a lot of duplicate code in the Sold and Winning 
states and we might want to clean those up. How would we 
do it? We could make State into an abstract class and build in 
some default behavior for the methods; after all, error messages 7 Dammit er 


like, “You already inserted a quarter,” aren’t going to be seen a gum ball 
by the customer. So all “error response” behavior could be beets not a 
generic and inherited from the abstract State class. computer! 


= The dispense() method always gets called, even if the crank is 
turned when there is no quarter. While the machine operates 
correctly and doesn’t dispense unless it’s in the right state, we 
could easily fix this by having turnCrank() return a boolean, 
or by introducing exceptions. Which do you think is a better 
solution? 


= All of the intelligence for the state transitions is in the State 
classes. What problems might this cause? Would we want to 
move that logic into the Gumball Machine? What would be 
the advantages and disadvantages of that? 


= Will you be instantiating a lot of GumballMachine objects? 
If so, you may want to move the state instances into static 
instance variables and share them. What changes would this 
require to the GumballMachine and the States? 
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fireside chats: state and strategy 


Fireside Chats 


Strategy State 


Tonight: A Strategy and State Pattern Reunion. 


Hey bro. Did you hear I was in Chapter 1? 
Yeah, word 1s definitely getting around. 


I was just over giving the Template Method guys a 

hand — they needed me to help them finish off their 

chapter. So, anyway, what is my noble brother up 

to? 
Same as always — helping classes to exhibit different 
behaviors in different states. 

I don’t know, you always sound like you’ve just 

copied what I do and you’re using different words 

to describe it. Think about it: I allow objects to 

incorporate different behaviors or algorithms 

through composition and delegation. You’re just 

copying me. 
T admit that what we do is definitely related, but my 
intent is totally different than yours. And, the way I 
teach my clients to use composition and delegation 
is totally different. 


Oh yeah? How so? I don’t get it. 


Well if you spent a little more time thinking about 
something other than yourself, you might. Anyway, 
think about how you work: you have a class you’re 
instantiating and you usually give it a strategy 
object that implements some behavior. Like, in 
Chapter | you were handing out quack behaviors, 
right? Real ducks got a real quack, rubber ducks 
got a quack that squeaked. 

Yeah, that was some fine work... and Pm sure you 

can see how that’s more powerful than inheriting 


ior, right? ; . 
your behavior, right: Yes, of course. Now, think about how I work; it’s 


totally different. 


Sorry, you’re going to have to explain that. 
Ys ¥! going P 
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Hey, come on, I can change behavior at runtime 
too; that’s what composition is all about! 


Well, I admit, I don’t encourage my objects to have 
a well-defined set of transitions between states. In 
fact, I typically like to control what strategy my 
objects are using. 


Yeah, yeah, keep living your pipe dreams brother. 
You act like you’re a big pattern like me, but check 
it out: I’m in Chapter 1; they stuck you way out in 
Chapter 10. I mean, how many people are actually 
going to read this far? 


That’s my brother, always the dreamer. 


the state pattern 


State 


Okay, when my Context objects get created, I may 
tell them the state to start in, but then they change 
their own state over time. 


Sure you can, but the way I work is built around 
discrete states; my Context objects change state 
over time according to some well defined state 
transitions. In other words, changing behavior is 
built in to my scheme ~ it’s how I work! 


Look, we’ve already said we’re alike in structure, but 
what we do is quite different in intent. Face it, the 
world has uses for both of us. 


Are you kidding? This is a Head First book and 
Head First readers rock. Of course they’re going to 
get to Chapter 10! 


refill exercise 


We almost forgot! 


ar er Se Ad 


st+-+4] a} + t 6 put | in the = nal set aL vas {| 4 
There one transition | we forgot to Pu Peake bat of) CT 
| Ty | | Ip | . -vefill-the-gumball 2 ii | | fe 
=_ on Ct im aa balls! haifa new diagram | iT cn implement vd fo 1-14 
— gumballs: umball machine we SuEB! 
CO - You did such a good job on the vest of an be oe PLL LEE 
i th =tanbar sachin tt i a. have hued doubt you ta add this in Py oa | | | a2 [ 4 = L T I T | ] 
ee dle Z a0 is Ef voee i Bi | ate The Mighty pal Eager Cl ai = L To - im | 
eT ane 7 a “veil Coo EECCeeert 
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erp your pencil 
NN We need you to write the refill() method for the Gumball machine. It has one 


argument — the number of gumballs you're adding to the machine — and should 
update the gumball machine count and reset the machine's state. 


You've done some amazing work! 
I've got some more ideas that 
are going to change the gumball 
industry and I need you to implement 
them. Shhhhh! I'll let you in on these 
ideas in the next chapter. 
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WUuUS BAES WHAT? 


Match each pattern with its description: 


Pattern Description 


Eneapsulate interchangeable 
State behaviorsanduse delegationto 
decide which behavior to use 


Subclasses decide how 
to implement steps in an 
algorithm 


Strategy 


Temp! ate Method Encapsulate state-based 
behavior and delegate 
behavior to the current state 
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It’s the end of another chapter; you’ve got enough 
patterns here to breeze through any job interview! 


00 Principles 
Ree hat varies: 
Eneapslace © - anhecitante: 


Favor eompositio 
Gon 


Program to ww evfates 
immplement avons 


se fat 
\a bi en for extension 
ou! 


Classes = 0 © oF ication 


but close ales Unis 
Don not windIPle 
alostractions: No new v supe 

be = tonerete Classes parte” that * ule 

e' on 

ly talk te You" friends: kime to sees 
Only 
ell tall you 
Dont tall vs) 


son 
hpovld have only one ve 
A class * Here’s our new 
ko change 


pattern. \f you ve 
managing state in 


a class, the State 
\ Pattern gives You 
00 Patterns z a technique ‘or 
S¢. . © encapsulating that 
es ae ' 
e iP X oat aa i = . state. 
wm QV Ao oy 38 a on R " 
va oP 4 c : ee ee: : . 
aa A yy" \ Asoker ie ; ie 
f ‘ i 7) ‘fsGh- - ee alter ' Se 
= a 3 State - Hes nay ake evant 
’ behavier © a i change 
“sa ‘ 1" « The object al area” 
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BULLET os 


the state pattern 


The State Pattern allows an 
object to have many different 
behaviors that are based on its 
internal state. 


Unlike a procedural state 
machine, the State Pattern 
represents state as a full-blown 
class. 


The Context gets its behavior 
by delegating to the current 
state object it is composed 
with. 


By encapsulating each state 
into a class, we localize any 
changes that will need to be 
made. 


The State and Strategy 
Patterns have the same class 
diagram, but they differ in 
intent. 


Strategy Pattern typically 
configures Context classes 
with a behavior or algorithm. 


State Pattern allows a Context 
to change its behavior as the 
state of the Context changes. 


State transitions can be 
controlled by the State classes 
or by the Context classes. 


Using the State Pattern will 
typically result in a greater 
number of classes in your 
design. 


State classes may be shared 
among Context instances. 
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SEB Exercise solutions 
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harpen your pencil 
eer yor 


Based on our first implementation, which of the following apply? 


Wa. 
Ws. 
fo 


oer your pencil 
Why don’t you implement it? To do this, carefully think through how 


pub 


public class SoldOutState implements State { refills the 4 
GumballMachine gumballMachine; 


lic SoldOutState (GumballMachine gumballMachine) 


this.gumballMachine = gumballMachine; 


lic void insertQuarter () 
System.out.print 


lic void ejectQuarter () 
System.out.print 


lic void turnCrank () 
System.out.print 


lic void dispense 
System.out.print 


(Choose all that apply.) 


This code certainly isn’t adhering to the WD”. State transitions aren’t explicit; they 
Open Closed Principle! are buried in the middle of a bunch of 


This code would make a FORTRAN wy Gonshizonal souk 
programmer proud. E. We haven’t encapsulated anything that 


3 Hiss tly , varies here. 
This design isn’t even very object Va 
oriented. FE. Further additions are likely to cause bugs 


in working code. 


We have one remaining class we haven't implemented: SoldOutState. 


the Gumball Machine should behave in each situation. Check your 
answer before moving on... 


Cold Out state, Wwe veally 


‘ ni until so 
tant ee bal Machine: 


wn cone 


{ 


{ 


In(“You can’t insert a quarter, the machine is sold out”); 


{ 


In(“You can’t eject, 


you haven’t inserted a quarter yet”); 


{ 


In(“You turned, but there are no gumballs”); 


Q { 
In(“No gumball dispensed”); 
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G harpen Your pencil 
IN To implement the states, we first need to define what the behavior will be 

when the corresponding action is called. Annotate the diagram below with the 
behavior of each action in each class; we’ve already filled in a few for you. 


Go to HasQuarterState 
« ie NoQuarterState 
Tell the customer you haven't inserted a quarter” 
Ps 


insertQuarter() 
ejectQuarter() 


Tell the customer “You turned, but there’s no quarter” 


Zz turnCrank() 
Tell the customer “you need to pay first” a ey 


Tell the customer “You can’t insert another quarter” 


HasQuarterStat 
Give back quarter, 90 to No Quarter state Oa ee 


insertQuarter() 


> ejectQuarter() 


—_—_——!— > turnCrank() 
; , dispense() 
Tell the éustomer, “no gumball dispensed” 


Go to SoldState 


Tell the eustomer “please wait, we've already giving you a gumball” 
Tell the customer “sorry, you already turned the crank” SS suet: 


insertQuarter() 


Tell the customer “turning twice doesn't get you another gumball” ~ ner 
Dispense one gumball. Cheek number of gumballs; if > O. go dispense() 


to NoQuarter state, otherwise, g0 to Sold Out state 


Tell the customer “the machine is sold out” 


Tell the customer “You haven't inserted a quarter yet” SoldOutState 
insertQuarter() 
Tell the customer “There are no gumballs” Oa ejectQuarter() 
eng turnCrank() 
Tell the customer “no gumball dispensed” > dispense() 


Tell the customer “please wait, we're already giving You a gumball” 


« i WinnerState 
Tell the customer “sorry, you already turned the érank moet 
Tell the ¢ “Lani : ) ‘i ejectQuarter() 
¢ customer “turning twice doesn't get you another gumball mo pea 
Dispense two gumballs. Check number of gumballs; if > O, dispense() 


—_—__—7 


go to NoQuarter state, otherwise, 90 to SoldOutState 


426 Chapter 10 


delegates to 
current — 


@) 


insertQuarter() Gumball Machine States 


insertQuarter() 


machine action 


22 ©« 


@umball Machine States 


dispense() 7 


Sol 


Here the machine 


gives out a gumball 
by calling, the internal s 


the state pattern 


Behind the Scenes: 
Self-Guided Tour 
Solution 


© 


delegates Gumball Machine States 


turnCrank() 
No ON 
turnCrank() current state 
i 
ae 


S OU 
i “baile 


machine action 


transitions to ) 
HasQuarter state 
transitions to 
Sold state 


—_ 


Gumball Machine States 


S UO 
“bali moo™ 


and then transitions wz 


dispense() action. 
to N oQuarter 
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Ge sharpen your pencil 
al 


» + FY 


+ 
WUuUS BOAES WHAT? 


Match each pattern with its description: 


Pattern Description 


Encapsulate interchangeable 
State behaviorsanduse delegationto 
decide which behavior to use 


Subclasses decide how 
to implement steps in an 
algorithm 


Strategy 


Encapsulate state-based 
behavior and delegate 
behavior to the current 
state 


Template Method 


We need you to write the refill() method for the Gumball machine. It has one 
argument, the number of gumballs you’re adding to the machine, and should 
update the gumball machine count and reset the machine’s state. 


void refill(int count) { 
this.count = count; 
state = noQuarterState; 


11 the Proxy Pattern 


Controlling ~* 
+ Object Access * 


With you as my Proxy, I'll be 
able to triple the amount of lunch 
money I can extract from friends! 


Ever play good cop, bad cop? You're the good cop and you provide all your 
services in a nice and friendly manner, but you don’t want everyone asking you for services, 
so you have the bad cop control access to you. That’s what proxies do: control and manage 
access. As you're going to see, there are /ots of ways in which proxies stand in for the 
objects they proxy. Proxies have been known to haul entire method calls over the Internet for 
their proxied objects; they’ve also been known to patiently stand in the place for some pretty 


lazy objects. 
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what’s the 


Hey team, I'd 
really like to get 
some better monitoring for 
my gumball machines. Can you 
find a way to get me a report of 
inventory and machine state? 


Sounds easy enough. If you remember, we’ve already 
got methods in the gumball machine code for getting the 
count of gumballs (getCount()), and getting the current 
state of the machine (getState()). 


All we need to do is create a report that can be printed out 
and sent back to the CEO. Hmmm, we should probably 
add a location field to each gumball machine as well; that 
way the CEO can keep the machines straight. 


Let’s just jump in and code this. We'll impress the CEO 
Remember the CEO o f with a very fast turnaround. 


Mighty Gumball, Ine.2 
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Coding the Monitor 


Let’s start by adding support to the GumballMachine class so that it 
can handle locations: 


public class GumballMachine { A loeation is just a String, 
// other instance variables 
Steime Ikoeerenemp 


public GumballMachine (String location, int count) { 
// other constructor code here 


this.location = location; Re The location is Passed into the 
} constructor and stored in the 
instance variable. 
public String getLocation() { 
return location; ™~ 
} Let’s also add a getter method to 


// other methods here grab the location when we need it. 


Now let’s create another class, GumballMonitor, that retrieves the machine’s 
location, inventory of gumballs and the current machine state and prints them 
in a nice little report: 


public class GumballMonitor { 


GumballMachine machine; — ig a - ws nes 
its constructor and assigns it to the 
public GumballMonitor(GumballMachine machine) { machine instance variable. 


this.machine = machine; 


public void report() { 
System.out.printlin(“Gumball Machine: ” + machine.getLocation()); 
System.out.printin(“Current inventory: ” + machine.getCount() + “ gumballs”); 
System.out.printin(“Current state: ” + machine.getState()); 


Our report 


bike. method just prints a report with 


inventory and the machine's state. 
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local gumball monitor 


Testing the Monitor 


We implemented that in no time. The CEO is going to be thrilled and amazed by our 
development skills. 


Now we just need to instantiate a GumballMonitor and give it a machine to monitor: 


public class GumballMachineTestDrive { Pass in a lotation and initial 4 of 
gumballs on the Command line. 
public static void main(String[] args) { 


int count = 0; 


) 
if (args.length < 2) { Don't forget to give 
System.out.printlin(“GumballMachine <name> <inventory>”) the constructor a 
System.exit (1); location and Count... 
} 
count = Integer.parselInt (args[1]); 


GumballMachine gumballMachine = new GumballMachine(args[0], count); 


and instantiate a monitor and Pass ita 


GumballMonitor monitor = new GumballMonitor Ran alt ; 
machine to provide a report on- 


// vest of test code here 


monitor. report () : File Edit Window Help FlyingFish 
} When we need a report on %$java GumballMachineTestDrive Seattle 112 
J 
} the machine, we call the 
veport() method. Gumball Machine: Seattle 


Current Inventory: 112 gumballs 
Current State: waiting for quarter 


And here's the output! 


The monitor output looks great, 
but I guess I wasn't clear. I need to 
monitor gumball machines REMOTELY! 

In fact, we already have the networks 

in place for monitoring. Come on guys, 
you're supposed to be the Internet 
generation! 
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Don't worry guys, I've 
been brushing up on my design 
patterns. All we need is a remote 
proxy and we'll be ready to go. 


Well, that will teach us to gather 
some requirements before we jump 
in and code. I hope we don't have 
to start over... 


G. us Frank 


Joe: A remote what? 


Frank: Remote proxy. Think about it: we’ve already got the monitor code written, right? We give the 
GumballMonitor a reference to a machine and it gives us a report. The problem is that monitor runs 
in the same JVM as the gumball machine and the CEO wants to sit at his desk and remotely monitor the 
machines! So what if we left our GumballMonitor class as is, but handed it a proxy to a remote object? 


Joe: I’m not sure I get it. 
Jim: Me neither. 


Frank: Let’s start at the beginning... a proxy is a stand in for a real object. In this case, the proxy acts 
just like it is a Gumball Machine object, but behind the scenes it is communicating over the network to 
talk to the real, remote GumballMachine. 


Jim: So you’re saying we keep our code as it is, and we give the monitor a reference to a proxy version 
of the GumballMachine... 


Joe: And this proxy pretends it’s the real object, but it’s really just communicating over the net to the 
real object. 


Frank: Yeah, that’s pretty much the story. 
Joe: It sounds like something that is easier said than done. 


Frank: Perhaps, but I don’t think it’ll be that bad. We have to make sure that the gumball machine 
can act as a service and accept requests over the network; we also need to give our monitor a way to get 
a reference to a proxy object, but we’ve got some great tools already built into Java to help us. Let’s talk 
a little more about remote proxies first... 
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remote proxy 


The role of the ‘remote proxy’ 


A remote proxy acts as a local representative to a remote object. What’s a “remote 
object?” It’s an object that lives in the heap of a different Java Virtual Machine 
(or more generally, a remote object that is running in a different address space). 
What’s a “local representative?” It’s an object that you can call local methods on 
and have them forwarded on to the remote object. 
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Your client object acts like it’s making remote method calls. 
But what it’s really doing is calling methods on a heap- 
loca] ‘proxy’ object that handles al] the low-level details of 
network communication. 
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the proxy pattern 


This is a pretty slick idea. We're 
going to write some code that takes a 
method invocation, somehow transfers it over 
the network and invokes the same method ona 
remote object. Then I presume when the call is 
complete, the result gets sent back over the 
network to our client. But it seems to me 
this code is going to be very 
tricky to write. 


Hold on now, we 
aren't going to write that code 
ourselves, it's pretty much built 
into Java's remote invocation 
functionality. All we have to do 
is retrofit our code so that it 
takes advantage of RMI. 


oe RAI 
PQOwerR 
Before going further, think about how you'd design a system to enable remote method invocation. 


How would you make it easy on the developer so that she has to write as little code as possible? 
How would you make the remote invocation look seamless? 


og 


Should making remote calls be totally transparent? Is that a good idea? What might be a problem 
with that approach? 


Warne 
GweR 
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Adding a remote proxy to the Gumball 
Machine monitoring code 


On paper this looks good, but how do we create a proxy that knows how to invoke a method on an 
object that lives in another JVM? 


Hmmm. Well, you can’t get a reference to something on another heap, right? In other words, you 
can’t say: 


Duck d = <object in another heap> 


Whatever the variable d is referencing must be in the same heap space as the code running the 
statement. So how do we approach this? Well, that’s where Java’s Remote Method Invocation 
comes in... RMI gives us a way to find objects in a remote JVM and allows us to invoke their 
methods. 


You may have encountered RMI in Head First Java; if not, we’re going to take a slight detour and 
come up to speed on RMI before adding the proxy support to the Gumball Machine code. 


So, here’s what we’re going to do: 


@ First, we’re going to take the RMI 
Detour and check RMI out. Even if 
you are familiar with RMI, you might 
want to follow along and check out the 


scenery. ‘An RMI Detour 


© Then we're going to take our 
GumballMachine and make it a remote 
service that provides a set of methods 
calls that can be invoked remotely. 


If you're new to RMI, 

take the detour that runs 
over the next few pages; 
otherwise, you might want to 
just quickly thumb through 


3) Then, we going to create a proxy that can Micsdetaup ae Greve. 


talk to a remote GumballMachine, again 
using RMI, and put the monitoring system 
back together so that the CEO can monitor 
any number of remote machines. 
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Remote methods 101 


Let’s say we want to design a system that allows us to call a local object that forwards each 
request to a remote object. How would we design it? We’d need a couple of helper objects 
that actually do the communicating for us. The helpers make it possible for the client to 

act as though it’s calling a method on a local object (which in fact, it is). The client calls a 
method on the client helper, as if the client helper were the actual service. The client helper 
then takes care of forwarding that request for us. 


od " 
> 


® 


An RMI Detour 


In other words, the client object thinks it’s calling a method on the remote service, because 
the client helper is pretending to be the service object. Pretending to be the thing with the 
method the client wants to call. 


But the client helper isn’t really the remote service. Although the client helper acts like it 
(because it has the same method that the service is advertising), the client helper doesn’t 
have any of the actual method logic the client is expecting. Instead, the client helper 
contacts the server, transfers information about the method call (e.g., name of the method, 
arguments, etc.), and waits for a return from the server. 


On the server side, the service helper receives the request from the client helper (through 

a Socket connection), unpacks the information about the call, and then invokes the real 
method on the real service object. So, to the service object, the call is local. It’s coming from 
the service helper, not a remote client. 


The service helper gets the return value from the service, packs it up, and ships it back (over 
a Socket’s output stream) to the client helper. The client helper unpacks the information 
and returns the value to the client object. 


miliar--- 
This should look Famili ee seins 
ko be the service bu . 
TIclient heap **° just a Prov or 
7 P Real Thing; 


Client dbject thinks 
it’s talking to the 
Real tee ? C 
khinks the chent Service PFs the 
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remote method invocation 


How the method call happens 


@) Client object calls doBigThing() on the client helper object. = 
[client heap Server heap J 


doBigThing() 


hens hee 


Tent oo” 


Client helper packages up information about the call 
(arguments, method name, etc.) and ships it over the 
network to the service helper. 


iz 
client heap | Server heap LJ 


“client wants to call a method" 


doBigThing() 


Trent hae 
Teng aoe 


® Service helper unpacks the information from the client helper, 
finds out which method to call (and on which object) and 


invokes the real method on the real service object. 
<= 7 S 
Server heap (| 


doBigThing() 


ie Client heap “client wants to call a method" 


doBigThing() 


member Unis is the 
pet with the REAL 
method looic- The one 
that does the real work. 
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@ The method is invoked on the service object, which returns An RMI Detour 


some result to the service helper. = 
‘ Server heap [ 


Service helper packages up information returned from the 
call and ships it back over the network to the client helper. 


oe 
cient heap | Server heap J 


packaged up result 


Trent Oe 
Trent Joe 


Client helper unpackages the returned values and returns 
them to the client object. To the client object, this was all 


transparent. 
my 
client heap Server heap [ 
ee 


result 


oS 
ens hare Seryi ce or 


Sep ee 
Tiers go” “PVice 30% 
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RMI: the big picture 


Java RMI, the Big Picture 


Okay, you've got the gist of how remote methods work; 
now you just need to understand how to use RMI to 
enable remote method invocation. 


What RMI does for you is build the client and service 
helper objects, right down to creating a client helper 
object with the same methods as the remote service. The 
nice thing about RMI is that you don’t have to write 

any of the networking or I/O code yourself. With your 
client, you call remote methods (1.e., the ones the Real 
Service has) just like normal method calls on objects 
running in the client’s own local JVM. 


RMI also provides all the runtime infrastructure to make 
it all work, including a lookup service that the client can 
use to find and access the remote objects. 


There is one difference between RMI calls and local 
(normal) method calls. Remember that even though to 
the client it looks like the method call is local, the client 
helper sends the method call across the network. So 
there is networking and I/O. And what do we know 
about networking and I/O methods? 


They’re risky! They can fail! And so, they throw 


exceptions all over the place. As a result, the client does 
have to acknowledge the risk. We'll see how in a few 


pages. 


RMI Nomenclature: in RMI, the client helper is a ‘stub’ and the 


service helper is a ‘skeleton’. 


This is 90109, 
to att as our 
| 
Q Client heap es 


Newer versions 


: of ava don't 
require an explicit 
skeleton object, 


but Something op 


Now let’s go through all the steps needed to make an object into a . he server side 
service that can accept remote calls and also the steps needed to is still handling 


allow a client to make remote calls. 


skeleton behavior. 


You might want to make sure your seat belt is fastened; there are 
a lot of steps and a few bumps and curves - but nothing to be too 


worried about. 
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Making the Remote service 


This is an overview of the five steps for making the remote service. In other words, the An RMI Detour 
steps needed to take an ordinary object and supercharge it so it can be called by a remote 

client. We'll be doing this later to our GumballMachine. For now, let’s get the steps down 

and then we'll explain each one in detail. 


Step one: 
Make a Remote Interface 
The remote interface defines the methods that 
a client can call remotely. It’s what the client — MyServicejava 
will use as the class type for your service. Both 


the Stub and actual service will implement 
this! 


nce) lass 
- The Real Service; the ¢ 
with the methods that do 


the veal work. [t implemen 
the remote interface: 


Step two: 


Make a Remote Implementation 

This is the class that does the Real Work. It 
has the real implementation of the remote MyServicelmpl java 
methods defined in the remote interface. 

It’s the object that the client wants to call 


methods on (e.g., our GumballMachine!). Spits out 
he actual | out two new 
Step three: Running, emie ‘et t : a ira for the 
; : ee entation Class-- elper ob; 
Generate the stubs and skeletons using rmic service implem Per objects. 
These are the client and server ‘helpers’. You 10 110 
don’t have to create these classes or ever look $rmic MyServiceImpl 03 30 


at the source code that generates them. It’s all 
handled automatically when you run the rmic 
tool that ships with your Java development kit. 


MyServicelmpl_Stub.class 


101101 |S 
10 110 1 
0110 


Step four: pote 
Start the RMI registry (rmiregistry) MyServicelmp|_Skel.class 
The rmiregistry is like the white pages of a phone 
book. It’s where the client goes to get the proxy %rmiregistry bis in 
(the client stub/helper object). Run Le 
a aan 
Step five: Lerrnind 


Start the remote service 


You have to get the service object up and running. Your 


. F F : ; 7 File Edit Window Help BeMerry 
service implementation class instantiates an instance 


of the service and registers it with the RMI registry. %java MyServiceImp1 
Registering it makes the service available for clients. 
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Step one: make a Remote interface 


@) Extend java.rmi.Remote 

Remote is a ‘marker’ interface, which means it has no methods. It has special 
meaning for RMI, though, so you must follow this rule. Notice that we say 
extends’ here. One interface is allowed to extend another interface. 


‘ 


This tells : 
interface is ond 


public interface MyRemote extends Remote { 


@ Declare that all methods throw a RemoteException 
The remote interface is the one the client uses as the type for the service. In 
other words, the client invokes methods on something that implements the 
remote interface. That something 1s the stub, of course, and since the stub is 
doing networking and I/O, all kinds of Bad Things can happen. The client 
has to acknowledge the risks by handling or declaring the remote exceptions. If 
the methods in an interface declare exceptions, any code calling methods on a 
reference of that type (the interface type) must handle or declare the exceptions. 


: is in \ava-rmi 
import java.rmi.* ; €— Remote interface is in j 


public interface MyRemote extends Remote { 
public String sayHello() throws RemoteException; 


@) Be sure arguments and return values are primitives or Serializable 


Arguments and return values of a remote method must be either primitive 

or Serializable. Think about it. Any argument to a remote method has to 

be packaged up and shipped across the network, and that’s done through 
Serialization. Same thing with return values. If you use primitives, Strings, and 
the majority of types in the API (including arrays and collections), you'll be fine. 
If you are passing around your own types, just be sure that you make your classes 
implement Serializable. 


public String sayHello() throws RemoteException; 


This return value is gonna be shi 
server back to the tlient, so it 
how args and return values get 


pped over the wire from the 
must be Serializable. That’s 
packaged up and sent. 
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to support remove 


the 
us that res - used 


te calls. 


“Every remote method call is 


considered ‘risky’. Deelaring 
RemoteException on ever 
method forces the elient 
to pay attention and 
acknowledge that things 
might not work. 


Check out Head First 
Java if you need to 
refresh Your memory 
on Serializable. 


the proxy pattern 


Step two: make a Remote implementation 
@) Implement the Remote interface An RMI Detour 


Your service has to implement the remote interface—the one with 
the methods your client is going to call. 


public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 
public String sayHello() { 
return “Server says, ‘Hey’”; The compiler will make sure that 
} Yon ve implemented all the methods 
// more code in class rom the interface you implement. |n 
} this case, there’s only a , 


@ Extend UnicastRemoteObject 


In order to work as a remote service object, your object needs some functionality 
related to ‘being remote’. The simplest way is to extend UnicastRemoteObject 
(from the java.rmi.server package) and let that class (your superclass) do the 
work for you. 


public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 


@) Write a no-arg constructor that declares a RemoteException 


Your new superclass, UnicastRemoteObject, has one little problem—its 

constructor throws a RemoteException. The only way to deal with this is to 

declare a constructor for your remote implementation, just so that you have a 

place to declare the RemoteException. Remember, when a class is instantiated, 

its superclass constructor is always called. If your superclass constructor throws 

an exception, you have no choice but to declare that your constructor also throws & apt ind, ie 
an exception. You don't have to pu ae eas 
the tonstructor: You Dieta elass 
way to declare that your me i" 
tonstructor throws an exception: 


public MyRemoteImpl() throws RemoteException { } 


@ Register the service with the RMI registry 


Now that you’ve got a remote service, you have to make it available to remote 
clients. You do this by instantiating it and putting it into the RMI registry (which 
must be running or this line of code fails). When you register the implementation 
object, the RMI system actually puts the stub in the registry, since that’s what the 
client really needs. Register your service using the static rebind() method of the 


i. cles Give your service a name ae ene re 
ry ; 7 . an reo 
MyRemote service = new MyRemoteImpl () ; to look it uP acres you bind the 

Naming. rebind(“RemoteHello”, service) ; with re PH sae the service for the 
} catch(Exception ex) {...} a al aad =n Khe stub in the registry: 
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Step three: generate stubs and skeletons 


Run rmic on the remote implementation class 
(not the remote interface) 


The rmic tool, which comes with the Java software 
development kit, takes a service implementation and 


creates two new classes, the stub and the skeleton. It uses 


a naming convention that is the name of your remote 
implementation, with either _Stub or _Skel added to 
the end. There are other options with rmic, including 
not generating skeletons, seeing what the source code 
for these classes looked like, and even using IIOP as 
the protocol. The way we’re doing it here is the way 
you'll usually do it. The classes will land in the current 
directory (i.e. whatever you did a cd to). Remember, 
rmic must be able to see your implementation class, so 
you'll probably run rmic from the directory where your 
remote implementation is located. (We’re deliberately 
not using packages here, to make it simpler. In the Real 
World, you'll need to account for package directory 
structures and fully-qualified names). 


Step four: run rmiregistry 


@ 


Bring up a terminal and start the rmiregistry. 


Be sure you start it from a directory that has access to 
your classes. The simplest way is to start it from your 
‘classes’ directory. 


Step five: start the service 


@) Bring up another terminal and start your service 


444, 


This might be from a main() method in your remote 
implementation class, or from a separate launcher class. 
In this simple example, we put the starter code in the 


implementation class, in a main method that instantiates the 


object and registers it with RMI registry. 
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MyRemotelmpl_Stub.class 


1o1101 PY 
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MyRemotelmpl_Skel.class 


File Edit Window Help Huh? 


srmiregistry 


Sjava MyRemoteImp1l 


the proxy pattern 


Complete code for the server side 


The Remote interface: 


moteException and Remote 
se oi java-rmi package. 


i Your interface MUST extend java-r 


public interface MyRemote extends Remote { 


F z : . : ce ar 
import java.rmi.*; interfa mi.Remote 


All of Your remote methods must 


public String sayHello() throws RemoteException; declave a RemoteExcepti 
ion. 


The Remote service (the implementation): 


sean the 
sett is 1 4 
otedoyel 
UnicastRem sekane: Lebbiett is the 
import java.rmi.*; i~—_ |; yar server ¥ tendin UnicastRemo Agate et. 
import java.rmi.server.*; Pg nee ] make 2 remote obje 


public class MyRemoteImpl extends UnicastRemoteObject implements MyRemote { 


' : £-— You have to implement all th ‘ You MUST 
public String sayHello() { ; e imPlement 
return “Server says, ‘Hey’”; interface methods, of course. But remote interfacell = 
notice that you do NOT have te : 
declare the RemoteException. 


public MyRemoteImpl() throws RemoteException { } Your super tlass constructor on | 
UnicastRemoteObject) declares an exception so 
YOU must write a tonstruetor, because it means 
that your tonstruttor is Calling visky code (its 
super constructor). 


public static void main (String[] args) { 


try { 
MyRemote service = new MyRemoteImpl () ; 
Naming. rebind (“RemoteHello”, service) ; Mak ‘ 
} catch(Exception ex) { ake the remote object Wey. 
ex.printStackTrace () ; ae rmiregistry using ye nr ‘ ae 
. re } 
} name you register it under is the ag ae 


| use to look it up in the RM| registry. 


will 


youarehere > 445 


how to get the stub object 


How does the client get the 
stub object? 


The client has to get the stub object (our proxy), since 
that’s the thing the client will call methods on. And that’s 
where the RMI registry comes in. The client does a 
‘lookup’, like going to the white pages of a phone book, 
and essentially says, “Here’s a name, and I'd like the stub 
that goes with that name.” 


Let’s take a look at the code we need to lookup and 
retrieve a stub object. 


X Cade Up Clase 


The élient always uses the remote 
interface as the type of the service. 
In faet, the client never needs to 
know the actual class name of Your 
remote service. 


MyRemote service = 4 


You have to east it to the 
interface, sinte the lookup 
method returns type Object. 
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lookup() is a statie method 
f of the Naming class. 


(MyRemote) Naming. lookup (“rmi://127.0.0.1/RemoteHello”) ; 


S—STNCNn"_ 


Fag 
The host name or |P 
address where the 


service is running, 


tk works: 


Vere s how 


the must be the hame 
hat the service was 
registered under. 


/ 
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die BY 


How it works... 


@) Client does a lookup on the RMI registry 
Naming. lookup (“rmi://127.0.0.1/RemoteHello”) ; 


@) RMI registry returns the stub object 
(as the return value of the lookup method) and RMI deserializes the stub 
automatically. You MUST have the stub class (that rmic generated for you) 
on the client or the stub won’t be deserialized. 


Client invokes a method on the stub, as if the 
stub IS the real service 


An RMI Detour 


the remote client 


Complete client code 


The Namin el 
— lookup) i 9 Class (Lo, doing the rmiregistry 


import java.rmi.*; in the javacrmi Packag 
e. 
public class MyRemoteClient { 
public static void main (String[] args) { 
new MyRemoteClient() .go() ; 


} 


£ ne eegistry 9S tye 
i i s out © ne Cast: 
public void go() { \& come 1 Lor ek v 
: o dont ba 
try { v4 Objet § 
ry 
MyRemote service = (MyRemote) Naming.lookup(“rmi://127.0.0.1/RemoteHello”) ; 
String s = service.sayHello() ; You need the |P address d the . used to 
an : 
System. out.printin(s) x ov hostname. bind/rebind the service: 
} catch (Exception ex) { It looks just like a regular old 
ex.printStackTrace(); method call! (Exeept it al 
} acknowledge the RemoteException.) 


How does the client get the stub class? 


—_— 

Geek Bits 

—————— 

Now we get to the interesting question. Somehow, some way, the client must have the stub class 
(that you generated earlier using rmic) at the time the client does the lookup, or else the stub won't 
be deserialized on the client and the whole thing blows up. The client also needs classes for any 
serialized objects returned by method calls to the remote object. In a simple system, you can simply 
hand-deliver these classes to the client. 


There's a much cooler way, although it’s beyond the scope of this book. But just in case you're 
interested, the cooler way is called “dynamic class downloading”. With dynamic class downloading, 
Serialized objects (like the stub) are “stamped”with a URL that tells the RMI system on the client where 
to find the class file for that object. Then, in the process of deserializing an object, if RMI can’t find the 
class locally, it uses that URL to do an HTTP Get to retrieve the class file. So you'd need a simple web 
server to serve up Class files, and you'd also need to change some security parameters on the client. 
There are a few other tricky issues with dynamic class downloading, but that’s the overview. 


For the stub object specifically, there’s another way the client can get the class. This is only available in 
Java 5, though. We'll briefly talk about this near the end of the chapter. 
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An RMI Detour 


Watch it! 


The top three things programmers do wrong with RMI are: 


1) Forget to start rmiregistry before starting remote service (when the service 1s registered using 
Naming.rebind(), the rmiregistry must be running!) 


2) Forget to make arguments and return types serializable (you won’t know until runtime; this 1s 
not something the compiler will detect.) 


3) Forget to give the stub class to the client. 


Q Client 


Server 


Don't forget, the tlient uses 101101 PS 


10 110 1 


the remote interface to call [3,2,8 eae 
methods on the stub. The ie ee MyServicelmol.c! SivSeivicelmol ‘Stic! 
rvicelmpl.cla : 

client JVM needs the stub Client.class MyServicelmpl_Stub.class YOSINIES NPE cioeS yoervicelmp!_otub.class 
class, but the client never mono D 

101101 
refers to the stub class in ron DS oot 10 20 

001 01 

code. The client always uses care Hirer 


the remote interface, as MyServicelmpl_Skel.class 


though Gace ee tate MyRemote.class MyRemote.class 
WERE the actual remote Server needs both the Stub and Skeleton 
object. classes, as well as the service and the 


remote interface. It needs the stub class 
because remember, the stub is substituted 
for the real service when the veal service 


is bound to the RM| registry. 
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remote gumbal! monitor 


Back to our GumballMachine 
remote proxy 


Okay, now that you have the RMI basics down, you’ve 
got the tools you need to implement the gumball 
machine remote proxy. Let’s take a look at how the 
GumballMachine fits into this framework: 


CE 0’ A desktop athe stub isa provy 


bo the remove 


“ _jF Gumball Machine- 
— Client heap 


END 
OF 
DETO Up 


Remote Gumball ‘ 
eis VM. Mathine 


Server heap 


This is our jai 

Monitor code, ' a oe 
uses a pro*y to The skeleton accepts the GymiballMi2eie 
talk to remote remote Calls and makes ee meote 50° . 
gumball machines- everything work on the ak’s 909 “ft ce 

service side. \ emote wer r) 
oe be cher 
use: 
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Getting the GumballMachine ready 
to be a remote service 


The first step in converting our code to use the remote proxy is to enable the 
GumballMachine to service remote requests from clients. In other words, 
we're going to make it into a service. To do that, we need to: 


1) Create a remote interface for the GumballMachine. This will provide a set 
of methods that can be called remotely. 


2) Make sure all the return types in the interface are serializable. 
3) Implement the interface in a concrete class. 


We'll start with the remote interface: 


ont forget to import java.rmi% 


import java.rmi.*; a 


public interface GumballMachineRemot xtends Remote { 
public int getCount() throws RemoteException; 
public String getLocation() throws RemoteException; 
public State getState() throws RemoteException; 


‘ 


. L 
Here are the methods were going to suppor 
Ngee sai — oe one throws RemoteException. 
e€ Primiti 
Serializable... 


This is the remote interface. 


We have one return type that isn’t Serializable: the State class. Let’s fix it up... 


import java.io.*; —=____ Serializable is in the java.io package: 


public interface Stat xtends Serializable { 


public void insertQuarter (); Then we just extend the Serializable 
public void ejectQuarter(); oe interface (which has no methods in it). 
pulive ven eee rane And now State in all the subélasses Can 


public void dispense(); ie kaneherved aieke the network. 
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remote interface for the gumbal! machine 


Actually, we’re not done with Serializable yet; we have one problem with State. As you may 
remember, each State object maintains a reference to a gumball machine so that it can call the 
gumball machine’s methods and change its state. We don’t want the entire gumball machine 
serialized and transferred with the State object. There is an easy way to fix or acleweitatien oP Siske, se 
public class NoQuarterState implements State { add the transient keyword to the 
transient GumballMachine gumballMachine; e_ Gumball Machine instante variable. This 
Lells the JVM not to sevialize this Feld. 
// all other methods here Note that this can be slightly dangerous 
if you try te access this Field once it's 
been serialized and transferred. 


We've already implemented our GumballMachine, but we need to make sure it can act as a service and 
handle requests coming from over the network. To do that, we have to make sure the GumballMachine 1s 
doing everything it needs to implement the GumballMachineRemote interface. 


As you’ve already seen in the RMI detour, this is quite simple, all we need to do 1s add a couple of things... 


. im h 
First, we need to import the GumballMachine is 


i packages. 
rmi packad f going, to subelass the 
UnieastRemoteObject; 
import java.rmi.*; this gives it the ability te GumballMachine also needs to 
import java.rmi.server.*; att as a remote service. G eerie aerate interface... 
public class GumballMachine 


extends UnicastRemoteObject implements GumballMachineRemote 


{ 


// instance variables here 


public GumballMachine (String location, int numberGumballs) 


throws RemoteException { 
// code here 


} 


public int getCount() { 
return count; 


and the constructor needs 
to throw a remote exception, 
public State getState() { =e oa supentlas aes 
return state; a That’s it! Nothing 
} changes here at all! 
public String getLocation() { Zz 


return location; 


} 


// other methods here 
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Registering with the RMI registry... 


That completes the gumball machine service. Now we just need to fire it up so it can 
receive requests. First, we need to make sure we register it with the RMI registry so 
that clients can locate it. 


We’re going to add a little code to the test drive that will take care of this for us: 


public class GumballMachineTestDrive { 


public static void main(String[] args) { 
GumballMachineRemote gumballMachine = null; 
int count; 


if (args.length < 2) { 
System.out.printlin(“GumballMachine <name> <inventory>”) ; 


Systemsexit (1); First we need to add a try/tateh block 
a around the gumball instantiation because our 


constructor an now throw exceptions. 


try { 
count = Integer.parseInt(args[1]); 


gumballMachine = 
new GumballMachine(args[0], count); 


Naming.rebind(*//” + args 1 ON. caine: gumballMachine) ; 


} catch (Exception e) { . k 
e.printStackTrace() ; We also add the call to Naming rebind, 


} whith publishes the GumballMachine stub 
} under the name gumballmachine. 
he using the “of ficial” 
i We re using the © ; 
Let’s go ahead and get this running... aaa ps way Gumball machines, YOu 
Run this first and Le should substitute your own 


machine name here: 


File Edit Window Help Huh? Vo 


Q 


% rmiregistry 


File Edit Window Help Huh? VU 


% java GumballMachineTestDrive seattle.mightygumball.com 100 


S ®_. This gets the GumballMachine up and running, 
Run this second. and registers it with the RMI registry. 
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gumball monitor client 


Now for the GumballMonitor client... 


Remember the GumballMonitor? We wanted to reuse it without 
having to rewrite it to work over a network. Well, we’re pretty much 
going to do that, but we do need to make a few changes. 


eause We ave 


e RMI package be 


We need to import th Lion Class below-~ 


“10 the RemoteExce? 
usind, vely on the remote 


. . ‘ RB ) ‘ 
import java.rmi.*; Now weve goind, to no tonerete 


her than 
interface vat 
public class GumballMonitor { nS, 2 allMachine class. 
GumballMachineRemote machine; ‘a - 
public GumballMonitor (GumballMachineRemote machine) { 


this.machine = machine; 


} 


public void report() { 
rey if 
System.out.printlin(“Gumball Machine: “ + machine.getLocation()); 
System.out.printin(“Current inventory: “ + machine.getCount() + “ gumballs”); 
System.out.printlin(“Current state: “ + machine.getState()); 


} catch (RemoteException e) { 
e.printStackTrace(); 


a We also need to catch any remote exceptions 
' that might happen as we try to invoke methods 
that are ultimately happening over the network. 


Frank was right; this 
is working out quite 
nicely! 
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Writing the Monitor test drive 


Now we've got all the pieces we need. We just need to write some 
code so the CEO can monitor a bunch of gumball machines: 


Here’s the monitor test drive. The 
CEO is going to run this! 
y locations 
es all the 
be i a ee going ko monitor: We a “ Lions 
* ane olations, 
public class GumballMonitorTestDrive { 


‘or each 


one 
ra machine. 
args) { 
location = {‘rmi://santafe.mightygumball.com/gumballmachine”, 


‘“rmi://boulder.mightygumball.com/gumballmachine”, 
‘“rmi://seattle.mightygumball.com/gumballmachine” }; 


public static void main(String[] 
String[] 


GumballMonitor[] monitor = 


new GumballMonitor[location.length]; 
for 


(int i=0;i < location.length; re We also treate an 


wee) 
try { array of monitors. 
GumballMachineRemote machine 


(GumballMachineRemote) Naming. lookup(location[i]); 

monitor[i] = new GumballMonitor (machine) ; 
System.out.println(monitor[i]); 

} catch (Exception e) { 


e.printStackTrace(); 


for(int i=0; 


Now we need to get a Proxy 


to eath remote machine. 
i < monitor.length; 


itt) { 
monitor[i].report(); 


\ 


Then we iterate through each 
machine and print out its report. 
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the gumball machine proxy 


ZX Cade Up Close 


Remember, Naming,lookup() is a 
statie method in the RMI package 


This returns a proxy to the remote that takes a location and service 
Gumball Machine (or throws an exception name and looks it up in the 
if one can't be located). rmiregistry at that location. 


try { —_~ { 
GumballMachineRemote machine = 


(GumballMachineRemote) Naming.lookup(location[i]); 


monitor[i] = new GumballMonitor (machine) ; 


} catch (Exception e) { 
e.printStackTrace(); 


} 


the remote 
*Y to umballM onitor 


to monitor: 


Once we get 3 Pre : 
machine, We ereate a new 


and pass it the machine 


Another demo for the CEO of Mighty Gumball... 


Okay, it’s time to put all this work together and give another demo. First let’s make 
sure a few gumball machines are running the new code: 


On eath machine, run rmiregistry in and then run the GumballMachine, giving it 
. perpen aan: atte a location and an initial gumball count. 
terminal window... 


File Eait_ Window Help Huh? _—<§$ 


C % rmiregistry & 


java GumballMachineTestDrive santafe.mightygumball.com 100 


% rmiregistry & 


% java GumballMachineTestDrive boulder.mightygumball.com 100 


% rmiregistry & 


% java GumballMachineTestDrive seattle.mightygumball.com 250 


popular machine! ips 
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And now let’s put the monitor in the hands of the CEO. 
Hopefully this time he'll love it: 


% java GumballMonitorTestDrive 


Gumball Machine: santafe.mightygumball.com 
Current inventory: 99 gumballs 


<a 


Current state: waiting for quarter 


The monitor iterates 
over each remote 


ee : machine and Calls 
Gumball Machine: boulder.mightygumball.com gets stint) 


Current inventory: 44 gumballs getCount() and 
Current state: waiting for turn of crank getStatel) methods. 


Gumball Machine: seattle.mightygumball.com 
Current inventory: 187 gumballs 


Current state: waiting for quarter 
9 ~ This is amazing; 
% it's going to revolutionize my 
business and blow away the 


competition! 
rN 


By invoking methods on the proxy, a remote call 

is made across the wire and a String, an integer 
and a State object are returned. Because we are 
using a proxy, the GumballMonitor doesn’t know, 
or care, that calls are remote (other than having 
to worry about remote exceptions). 
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proxy behind the scenes 


This worked great! But 
I want to make sure I 
understand exactly what's 
going on... 


Behind 
the Scenes 


@ ~The CEO runs the monitor, which first grabs the proxies to the remote 
gumball machines and then calls getState() on each one (along with 
getCount() and getLocation()). 


CEO's desktoP 


Remote Gumball : 
with a wn Mathine 
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@  getState() is called on the proxy, which forwards the call to the remote 
service. The skeleton receives the request and then forwards it to the 
gumball machine. 


ao 


€ 


Sk el eto’ Sup ballnno’ 


3) GumballMachine returns the state to the skeleton, which serializes it and 
transfers it back over the wire to the proxy. The proxy deserializes it and 
returns it as an object to the monitor. 


Serializéd 


% State E 
tate bs mass 
QO. 
Ss S) \ & 


Combai no 


Likewise, the GumballMachine 


) M, 
nt changed at a implements another interface and 


The monitor has 


. counter mas 
+ it knows ed the may throw a remote exception in its 
eae exceptions: i ne tate vather constructor, but other than that, the 
GumballMathineRemore re tode hasn't changed. 
Le implemen tarier 


than a contre 


We also have a small bit of code to register and locate stubs using the 
RMI registry. But no matter what, if we were writing something to 
work over the Internet, we'd need some kind of locator service. 
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The Proxy Pattern defined 


We've already put a lot of pages behind us in this chapter; as you 
can see, explaining the Remote Proxy is quite involved. Despite 
that, you'll see that the definition and class diagram for the Proxy 
Pattern is actually fairly straightforward. Note that Remote Proxy is 
one implementation of the general Proxy Pattern; there are actually 
quite a few variations of the pattern, and we'll talk about them later. 
For now, let’s get the details of the general pattern down. 


Here’s the Proxy Pattern definition: 
y 


Use the Proxy 


The Proxy Pattern provides a surrogate or Pattern to create a 


placeholder for another object to control access to it. 


representative object 


that controls access 


Well, we’ve seen how the Proxy Pattern provides a surrogate or to another object 
placeholder for another object. We’ve also described the proxy as J : 


a “representative” for another object. which may he remote, 
But what about a proxy controlling access? That sounds a little . 
strange. No worries. In the case of the gumball machine, just expensive to create or 


think of the proxy controlling access to the remote object. The : d f : 
proxy needed to control access because our client, the monitor, in needa Or secur ing. ‘ 
didn’t know how to talk to a remote object. So in some sense the 

remote proxy controlled access so that it could handle the network 

details for us. As we just discussed, there are many variations of 

the Proxy Pattern, and the variations typically revolve around the 

way the proxy “controls access.” We’re going to talk more about 

this later, but for now here are a few ways proxies control access: 


= As we know, a remote proxy controls access to a 
remote object. 


=" A virtual proxy controls access to a resource that is 
expensive to create. 


= A protection proxy controls access to a resource 
based on access rights. 


Now that you’ve got the gist of the general pattern, check out the 
class diagram... 
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Both the Proxy and 


lL Re alSubject 


Subject intervace- 


<<interface>> 


Subject allows ary client 


request() the proxy , 
RealSubjec ; 


subject 


Proxy 


RealSubject 


request() 


request() 


The RealSubject is 
usually the object 
that does most 

of the real work; 
the Proxy controls 
access to it. 


The Proxy often instantiates 
or handles the ereation of 
the RealSubject. 


Let’s step through the diagram... 


First we have a Subject, which provides an interface for the RealSubject and the Proxy. 


the proxy pattern 


the 
implement the 
This 
to trea 


aust like the 


The Proxy keeps 9 
vekerence . 
Subjects so it Can 
forward reyes 
bo the Subject 


when necessary: 


By implementing the same interface, the Proxy can be substituted for the RealSubject 


anywhere it occurs. 


The RealSubject is the object that does the real work. It’s the object that the Proxy 


represents and controls access to. 


The Proxy holds a reference to the RealSubject. In some cases, the Proxy may be 
responsible for creating and destroying the RealSubject. Clients interact with the 
RealSubject through the Proxy. Because the Proxy and RealSubject implement the 
same interface (Subject), the Proxy can be substituted anywhere the subject can be 
used. The Proxy also controls access to the RealSubject; this control may be needed 
if the Subject 1s running on a remote machine, if the Subject 1s expensive to create in 
some way or if access to the subject needs to be protected in some way. 


Now that you understand the general pattern, let’s look at some other ways of using 


proxy beyond the Remote Proxy... 
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virtual proxy 


Get ready for Virtual Proxy 


Okay, so far you’ve seen the definition of the Proxy Pattern and you've taken a look 
at one specific example: the Remote Proxy. Now we’re going to take a look at a different 
type of proxy, the Virtual Proxy. As you'll discover, the Proxy Pattern can manifest 
itself in many forms, yet all the forms follow roughly the general proxy design. Why 
so many forms? Because the proxy pattern can be applied to a lot of different use 
cases. Let’s check out the Virtual Proxy and compare it to Remote Proxy: 


Remote Proxy 


With Remote Proxy, the proxy 
acts as a local representative 
for an object that lives ina 
different JVM. A method call 

on the proxy results in the call 
being transferred over the wire, 
invoked remotely, and the result 
being returned back to the proxy 
and then to the Client. 


equest) 


We know this diagram 
pretty well by now... 


Big “expensive to treate” object 


The proxy creates 
the RealSubject 
est) when it’s needed. 


Virtual Proxy 


Virtual Proxy acts as a 
representative for an object that 
may be expensive to create. The 
Virtual Proxy often defers the 
creation of the object until it 

is needed; the Virtual Proxy 

also acts as a surrogate for 

the object before and while it 

is being created. After that, the 
proxy delegates requests directly to 
the RealSubject. 


requ 


Proxy 


Ge 
Ch Reais io 
liens The proxy ea ilhendl the request, or i SHES 


the RealSubject has been treated, delegate 
the ¢alls to the RealSubject. 
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Displaying CD covers 


Let’s say you want to write an application that displays your favorite compact disc 
covers. You might create a menu of the CD titles and then retrieve the images 
from an online service like Amazon.com. If you’re using Swing, you might create 
an Icon and ask it to load the image from the network. The only problem 1s, 
depending on the network load and the bandwidth of your connection, retrieving 
a CD cover might take a little time, so your application should display something 
while you are waiting for the image to load. We also don’t want to hang up the 
entire application while it’s waiting on the image. Once the image is loaded, the 
message should go away and you should see the image. 


An easy way to achieve this is through a virtual proxy. The virtual proxy can 
stand in place of the icon, manage the background loading, and before the 
image is fully retrieved from the network, display “Loading CD cover, please 
wait...”. Once the image is loaded, the proxy delegates the display to the Icon. 


Choose the 
album é 
oe of eee CD Cover Viewer 


Your liking, here. 


Favorite CDs 


Buddha Bar 
Selected Ambient Works, Vol. 2 
Northern Exposure 

Ima 
MCMXC A.D. 
Karma 
Ambient: Music for Airports 


are 


eee CD Cover Viewer 
Favorite CDs 


While the CD cover 
is loading, the Proxy 
displays a message. 


Loading | 1 lease wail... | 


eee CD Cover Viewer 
Favorite CDs 


\s 
the CD over 
‘ny \oaded: ane prory 
diselays fe wage 


image proxy controls access 


Designing the CD cover Virtual Proxy 


Before writing the code for the CD Cover Viewer, let’s look at the class diagram. 
You'll see this looks just like our Remote Proxy class diagram, but here the proxy is 
used to hide an object that is expensive to create (because we need to retrieve the data 
for the Icon over the network) as opposed to an object that actually lives somewhere 
else on the network. 


This is the Swing 
leon interface used ~~> ae 
to display images in a 


; getlconWidth() 
user intertace. getlconHeight() 


paintlcon() 


subject 


Imagelcon ImageProxy 


getlconWidth() getlconWidth() 
ye getlconHeight() getlconHeight() 
paintlcon() paintlcon() 


This is Javax-swing./mageléon, 


a ¢lass that displays an Image. This is our proxy, which first 


displays a message and then when 
the image is loaded, delegates to 
Imageleon to display the image. 


How ImageProxy is going to work: 


@ ImageProxy first creates an Imagelcon and starts 
loading it from a network URL. 


@ While the bytes of the image are being retrieved, 
ImageProxy displays “Loading CD cover, please 
wait...”. 


@ When the image is fully loaded, ImageProxy del- 
egates all method calls to the image icon, including 
painticon(), getWidth() and getHeight(). 


@ if the user requests a new image, we'll create a 
new proxy and start the process over. 


the proxy pattern 


Writing the Image Proxy 


The |mageProry <<interface>> 
implements the leon Icon 


interface: geticonWiath() 
class ImageProxy implements Icon { salsosiveiel 


ImageIcon imagelIcon; paintlcon() 

URL imageURL; 

Thread retrievalThread; ‘ 

boolean retrieving = false; The imageleon is the REAL icon that we 
eventually want to display when it’s loaded. 


public ImageProxy(URL url) { imageURL = url; } 


. a . to 
public int getIconWidth() { — We pass the URL aha ge in 
if (imageIcon != null) { the constructor. This is the vgs we 
return imageIcon.getIconWidth (); need to display onte it's loaded. 


} else { 
return 800; 


- We return a default width and height 


i i ton is loaded; then we 
public int getIconHeight() { until the imagel n ; 


‘ . on: 
if (imageIcon != null) { Ee turn it over to the imagele n 
return imageIcon.getIconHeight (); 
} else { 


return 600; 


public void paintIcon(final Component c, Graphics g, int x, int y) { 


if (imageIcon != null) { 
imageIcon.paintIcon(c, g, x, y); 
} else { 


g.drawString (“Loading CD cover, please wait...”, x+300, y+190); 
if (!retrieving) { 
retrieving = true; 


retrievalThread = new Thread(new Runnable() { 
public void run() { 

try { 
imageIcon = new ImageIcon(imageURL, “CD Cover”); 
c.repaint(); 

} catch (Exception e) { 
e.printStackTrace (); Here’s where things get interesting. 

This Code paints the icon on the 


F streen (by delegating to the 
ee ges start(); imagel¢on). However, if we don't have 
, a fully created Imageleon, then we 


} treate one. Let’s look at this closer 
: on the next page... 
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image proxy up close 


ZX Cade Up Clase 


This method is Called when it’s time to paint the icon on the sereen. 


\ 


public void paintIcon (final Component c, Graphics g, int x, int y) { 
if (imageIcon != null) { |f we've got an i¢on already, we 9o 


<— ahead and tell it to paint itself. 


imageIcon.paintIcon(c, g, x, y); 
} else { 


g.drawString(“Loading CD cover, please wait...”, x+300, y+190); 
if ('retrieving) { c Otherwise 
we 


retrieving = true; Fisplay the 
retrievalThread = new Thread(new Runnable() { loading message. 
public void run() { 
try { 
imageIcon = new ImageIcon(imageURL, “CD Cover”) ; 
c.repaint() ; 
} catch (Exception e) { 
e.printStackTrace () ; 
} 
} 
}); 


retrievalThread.start() ; 


goin 
Close on 


» 
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Code Way Up Close 


If we arent already trying to retrieve the image-.. 
( then it’s time to start retrieving it (in ease You 


f int, So We 
d , only one thread calls paint, 
Sold: ig se an terms of thread safety). 


if (!retrieving) { A tie dott want to hang uP the 


, 7 
aiid ieee entire user interface, so we re 
oing, to use another thread to 


tri 1Th d= Thread (new Runnable . 
retrieva rea new ( () { velceve tie image: 


public void run() { 
try { 
imageIcon = new ImageIcon(imageURL, “CD Cover”) ; 
c.repaint() ; 


In Our thread We 


é the 


} catch (Exception e) { a instantigd, 
e.printStackTrace () ; Con object. 

@ | bons ie Its 
hen we have the image, 

He we tell Swing that we 


retrievalThread.start() ; need to be repainted. 


ctor wi 
return wsdl i not 
Image is loaded. 


So, the next time the display is painted after the Imagelcon is instantiated, the paintleon 
method will paint the image, not the loading message. 
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Design Puzzle 


The ImageProxy class appears to have two states that are controlled 
by conditional statements. Can you think of another pattern that 
might clean up this code? How would you redesign ImageProxy? 


class ImageProxy implements Icon { 
// instance variables & constructor here 


public int getIconWidth() { 
if (imageIcon != null) { 
return imagelIcon.getIconWidth (); _ 


} else { 
return 800; ie” 


Two states 


public int getIconHeight() { 
if (imageIcon != null) { 
return imagelIcon.getIconHeight (); Two: cakes 


} else { 
return 600; “L’ 


public void paintIcon(final Component c, Graphics g, int x, 
if (imageIcon != null) { 
imageIcon.paintIcon(c, g, xX, y)? 
} else { 
g.drawString(“Loading CD cover, please wait...”, x+300, y+190); 
// more code here 


the proxy pattern 


Testing the CD Cover Viewer 


Okay, it's time to test out this fancy new virtual proxy. Behind the 
scenes we've been baking up a new ImageProxyTestDrive that sets up 
the window, creates a frame, installs the menus and creates our proxy. 
We don't go through all that code in gory detail here, but you can 
always grab the source code and have a look, or check it out at the end 
of the chapter where we list all the source code for the Virtual Proxy. 


Here’s a partial view of the test drive code: 


public class ImageProxyTestDrive { 
ImageComponent imageComponent; 
public static void main (String[] args) throws Exception { 


ImageProxyTestDrive testDrive = new ImageProxyTestDrive(); 
} 
public ImageProxyTestDrive() throws Exception{ Here we éreate an image Proxy and set 
it to an initial URL. Whenever you 
// set up frame and menus choose a selection from the CD menu, 


you'll get a new image proxy. 
Icon icon = new ImageProxy(initialURL) ; 
imageComponent = new ImageComponent (icon) ; sh 
frame.getContentPane().add(imageComponent) ; 


Finally we add the proxy to the frame 
so it ¢an be displayed. 


Now let’s run the test drive: 


File Edit Window Help JustSomeOfTheCDsThatGotUsThroughThisBook 


java ImageProxyTestDrive 


Running ImageProxy TestDrive should 
give you a window like this. 


eoe 
Favorite CDs 


Things to try... 


1) Use the menu to load different CD covers; watch the 
proxy display “loading” until the image has arrived. 


(2) Resize the window as the “loading” message is 
displayed. Notice that the proxy is handling the loading 
without hanging up the Swing window. 


3) Add your own favorite CDs to the ImageProxyTestDrive. 
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behind the scenes with image proxy 


What did we do? 


Behind 
We created an ImageProxy for the display. The paintIcon() 
method is called and ImageProxy fires off a thread to the Scenes 
retrieve the image and create the ImageIcon. 


tes a 
goeProxy create 
- Kiwead instantiate Ene 
FM |magelton which star Some image 
Ln retrieving the image: server on 
F os i the Internet 


get image 


displays loading 
message 


image retrieved 


© “At some point the image is returned and 
the ImageIcon fully instantiated. 


Lnagetco® 


@ After the ImageIcon is created, the next time paintIcon() is 
called, the proxy delegates to the ImageIcon. 


paintIcon() 


paintIcon() 


displays the real image 
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: The Remote Proxy and Virtual 
Proxy seem so different to me; are 
they really ONE pattern? 


A: You'll find a lot of variants of the 
Proxy Pattern in the real world; what 
they all have in common is that they 
intercept a method invocation that 

the client is making on the subject. 
This level of indirection allows us to 

do many things, including dispatching 
requests to a remote subject, providing 
a representative for an expensive 
object as it is created, or, as you'll see, 
providing some level of protection that 
can determine which clients should be 
calling which methods. That’s just the 
beginning; the general Proxy Pattern 
can be applied in many different ways, 
and we'll cover some of the other ways 
at the end of the chapter. 


Q: ImageProxy seems just like 
a Decorator to me. | mean, we are 
basically wrapping one object with 
another and then delegating the 
calls to the Imagelcon. What am | 
missing? 


A: Sometimes Proxy and Decorator 
look very similar, but their purposes are 
different: a decorator adds behavior to 
a class, while a proxy controls access 
to it. You might say, “Isn't the loading 
message adding behavior?” In some 


thereyare no 


Dumb Questions 


ways it is; however, more importantly, 
the ImageProxy is controlling access 
to an Imagelcon. How does it control 
access? Well, think about it this way: 
the proxy is decoupling the client from 
the Imagelcon. If they were coupled 
the client would have to wait until each 
image is retrieved before it could paint 
its entire interface. The proxy controls 
access to the Imagelcon so that before 
it is fully created, the proxy provides 
another on screen representation. 
Once the Imagelcon is created the 
proxy allows access. 


+ How dol make clients use the 
Proxy rather than the Real Subject? 


A: Good question. One common 
technique is to provide a factory that 
instantiates and returns the subject. 
Because this happens in a factory 
method we can then wrap the subject 
with a proxy before returning it. The 
client never knows or cares that it’s 
using a proxy instead of the real thing. 


Q: I noticed in the ImageProxy 
example, you always create a new 
Imagelcon to get the image, even 

if the image has already been 
retrieved. Could you implement 
something similar to the lmageProxy 
that caches past retrievals? 


the proxy pattern 


A: You are talking about a spe- 
cialized form of a Virtual Proxy called 


a Caching Proxy. A caching proxy 
maintains a cache of previous created 
objects and when a request is made it 
returns cached object, if possible. 


We're going to look this and at several 
other variants of the Proxy Pattern at 
the end of the chapter. 


Q: | see how Decorator and Proxy 
relate, but what about Adapter? An 
adapter seems very similar as well. 


A: Both Proxy and Adapter sit in 
front of other objects and forward 
requests to them. Remember that 
Adapter changes the interface of the 
objects it adapts, while the Proxy 
implements the same interface. 


There is one additional similarity that 
relates to the Protection Proxy. A 
Protection Proxy may allow or disallow 
a client access to particular methods 
in an object based on the role of the 
client. In this way a Protection Proxy 
may only provide a partial interface to 
a client, which is quite similar to some 
Adapters. We are going to take a look 
at Protection Proxy in a few pages. 
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fireside chats: proxy and decorator 


Fireside Chats 


Proxy 


Hello, Decorator. I presume you're here 
because people sometimes get us confused? 


Me copying your ideas? Please. I control access 
to objects. You just decorate them. My job is 
so much more important than yours it’s just not 
even funny. 


Fine, so maybe you're not entirely frivolous... 
but I still don’t get why you think ’'m copying 
all your ideas. I’m all about representing my 
subjects, not decorating them. 


I don’t think you get it, Decorator. I stand in for 
my Subjects; I don’t just add behavior. Clients 
use me as a surrogate of a Real Subject, because 
I can protect them from unwanted access, or keep 
their GUIs from hanging up while they’re waiting 
for big objects to load, or hide the fact that their 
Subjects are running on remote machines. I’d say 
that’s a very different intent from yours! 
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Tonight’s talk: Proxy and Decorator get intentional. 


Decorator 


Well, I think the reason people get us confused 
is that you go around pretending to be an 
entirely different pattern, when in fact, you’re 
just a Decorator in disguise. I really don’t 
think you should be copying all my ideas. 


“Just” decorate? You think decorating is some 
frivolous unimportant pattern? Let me tell 
you buddy, I add behavior. That’s the most 
important thing about objects - what they do! 


You can call it “representation” but if it looks 
like a duck and walks like a duck... I mean, just 
look at your Virtual Proxy; it’s just another 
way of adding behavior to do something while 
some big expensive object is loading, and your 
Remote Proxy is a way of talking to remote 
objects so your clients don’t have to bother 
with that themselves. It’s all about behavior, 
just like I said. 


Call it what you want. I implement the same 
interface as the objects I wrap; so do you. 


Proxy 


Okay, let’s review that statement. You wrap 
an object. While sometimes we informally say 
a proxy wraps its Subject, that’s not really an 
accurate term. 


Think about a remote proxy... what object am 
I wrapping? The object ’m representing and 
controlling access to lives on another machine! 
Let’s see you do that. 


Sure, okay, take a virtual proxy... think about 
the CD viewer example. When the client first 
uses me as a proxy the subject doesn’t even 
exist! So what am I wrapping there? 


I never knew decorators were so dumb! Of 
course I sometimes create objects, how do you 
think a virtual proxy gets its subject! Okay, you 
just pointed out a big difference between us: 
we both know decorators only add window 
dressing; they never get to instantiate anything, 


Hey, after this conversation ’'m convinced 
you're just a dumb proxy! 


Very seldom will you ever see a proxy get into 
wrapping a subject multiple times; in fact, if 
you're wrapping something 10 times, you 
better go back reexamine your design. 
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Decorator 


Oh yeah? Why not? 


Okay, but we all know remote proxies are kinda 
weird. Got a second example? I doubt it. 


Uh huh, and the next thing you'll be saying is 
that you actually get to create objects. 


Oh yeah? Instantiate this! 


Dumb proxy? Id like to see you recursively 
wrap an object with 10 decorators and keep 
your head straight at the same time. 


Just like a proxy, acting all real when in fact you 
just stand in for the objects doing the real work. 
You know, [ actually feel sorry for you. 


protection proxy 


Using the Java API’s Proxy to create a 
protection proxy 


Java’s got its own proxy support right in the java.lang reflect package. With this package, Java 
lets you create a proxy class on the fly that implements one or more interfaces and forwards 
method invocations to a class that you specify. Because the actual proxy class is created at 
runtime, we refer to this Java technology as a dynamic proxy. 


We're going to use Java’s dynamic proxy to create our next proxy implementation (a 
protection proxy), but before we do that, let’s quickly look at a class diagram that shows how 
dynamic proxies are put together. Like most things in the real world, it differs shghtly from 
the classic definition of the pattern: 


<<interface>> 


<<interface>> 
Subject 


InvocationHandler 


request() 


invoke() 


S— The Proxy now ani 


of two Classes: 


RealSubject 
request() 


Proxy InvocationHandler 


requesti) invoke() 


thane is generated 

b a d im | m 

the eh me You supply the Invotationtandler, which gets passed 

interface. : all method calls that are invoked on the Proxy: 
The |nvotationttandler tontrols access to the 


methods of the RealSubject:- 


Because Java creates the Proxy class for you, you need a way to tell the Proxy class what to do. You can’t 
put that code into the Proxy class like we did before, because you’re not implementing one directly. So, if 
you can’t put this code in the Proxy class, where do you put it? In an InvocationHandler. The job of the 
InvocationHandler is to respond to any method calls on the proxy. Think of the InvocationHandler as the 
object the Proxy asks to do all the real work after it’s received the method calls. 


Okay, let’s step through how to use the dynamic proxy... 
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Matchmaking in Objectville — 


Hot 


Every town needs a matchmaking service, right? You’ve risen to the task and 
implemented a dating service for Objectville. You’ve also tried to be innovative by 
including a “Hot or Not” feature in the service where participants can rate each 
other — you figure this keeps your customers engaged and looking through possible 
matches; it also makes things a lot more fun. 


Your service revolves around a Person bean that allows you to set and get information 
about a person: 


’ 
erkate We 


as | int 
veh ie implement aor 
¢ ‘ te . 
| ; ; rie ans get information 
e Pe ? 
sneer, ales a 
HotOrNot rating (i lo) 


public interface PersonBean { 


String getName (); 

String getGender(); 
String getInterests(); 
int getHotOrNotRating(); 


void setName (String name) ; 

void setGender (String gender) ; 

void setInterests (String interests); 
void setHotOrNotRating(int rating); 


} 
/ sitotOrNotRabng nae . 
integer an a sit | 
We ean also set the same 3 aver 39E ene 


information through the 
respective method calls. 


Now let’s check out the implementation... 
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personbean needs protecting 


The PersonBean implementation 


The PersonBean|mpl implements the PersonBean interface 


v 


public class PersonBeanImpl implements PersonBean { 
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String name; 
String gender; 

ite ; ————— The instance variabl 
String interests; es. 
int rating; 
int ratingCount = 0; 


public String getName() { 
return name; All the getter methods; they each return 
: Z—— the appropriate instance variable... 


public String getGender() { 
return gender; 


} 


public String getInterests() { 


return interests; euies oe 
gettotOrNotRating(), whith 
h 
public int getHotOrNotRating() { Cs computes the average of : e 
if (ratingCount == 0) return 0; ratings by dividing the ratings 
return (rating/ratingCount) ; by the ratingCount, 


public void setName(String name) { 


this.name = name; me And here’s all the setter 


methods, which set the 


public void setGender (String gender) { corresponding instance variable. 
this.gender = gender; 


} 


public void setInterests(String interests) { 
this.interests = interests; 


} 


Finally, the 
public void setHotOrNotRating(int rating) { setHotOrNotRat 0 
this.rating += rating; el method Hetewens ty bo 
vatingCount++; ratingCount aia. : tal 
e 


| rating to the Funning total. 
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I wasn't very successful finding 
dates. Then I noticed someone had changed 
my interests. I also noticed that a lot of people 
are bumping up their HotOrNot scores by giving 
themselves high ratings. You shouldn't be able 
to change someone else's interests or give 


yourself a rating! 


While we suspect other factors may be keeping Elroy from getting 

dates, he is right: you shouldn’t be able to vote for yourself or to change 
another customer’s data. The way our PersonBean is defined, any client 
can call any of the methods. 


This is a perfect example of where we might be able to use a Protection 
Proxy. What’s a Protection Proxy? It’s a proxy that controls access to 
an object based on access rights. For instance, if we had an employee 
object, a protection proxy might allow the employee to call certain 
methods on the object, a manager to call additional methods (like 
setSalary()), and a human resources employee to call any method on the 
object. 


In our dating service we want to make sure that a customer can set his 
own information while preventing others from altering it. We also want 
to allow just the opposite with the HotOrNot ratings: we want the other 
customers to be able to set the rating, but not that particular customer. 
We also have a number of getter methods in the PersonBean, and 
because none of these return private information, any customer should 
be able to call them. 
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five minute drama 


Five minute drama: protecting subjects 


The Internet bubble seems a distant memory; those were the days 
when all you needed to do to find a better, higher-paying job was to 


walk across the street. Even agents for software developers were 
in vogue... 


I'd like to make an 
offer, can we get her on 
the phone? 


She's tied up ... uh... 
ina meeting right now, 
what did you have in 
mind? 


etkion oF)? 


Like 2 yok ets access 


<— the agent pro 
ko his sujet 
certain calls 


Joe DotCom 


Come 
on. You're wasting our 
time here! Not a chance! 
Come back later with a 
better offer. 


We think we can 
meet her current 
salary plus 15%. 
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Big Picture: creating a Dynamic Proxy 


for the PersonBean 


We have a couple of problems to fix: customers shouldn’t be changing their own 
HotOrNot rating and customers shouldn’t be able to change other customers’ personal 
information. To fix these problems we’re going to create two proxies: one for accessing 
your own PersonBean object and one for accessing another customer’s PersonBean 


object. That way, the proxies can control what requests can be made in each 


circumstance. 


To create these proxies we’re going to use the 
Java API’s dynamic proxy that you saw a few 
pages back. Java will create two proxies for us; 
all we need to do 1s supply the handlers that 
know what to do when a method is invoked on 
the proxy. 


Step one: 
Create two InvocationHandlers. 


InvocationHandlers implement the behavior 
of the proxy. As you'll see Java will take care 
of creating the actual proxy class and object, 
we just need to supply a handler that knows 
what to do when a method is called on it. 


Step two: 


Write the code that creates the 
dynamic proxies. 

We need to write a little bit of code to 
generate the proxy class and instantiate it. 
We'll step through this code in just a bit. 


Step three: 


Wrap any PersonBean object with 
the appropriate proxy. 


When we need to use a PersonBean object, 
either it’s the object of the customer himself 
(in that case, will call him the “owner”), or it’s 
another user of the service that the customer is 
checking out (in that case we’ll call him “non- 
owner”). 


In either case, we create the appropriate proxy 
for the PersonBean. 


request() 


RealSubject Proxy 


Remember this diagram 
from a few pages back. 


<<interface>> 
Subject 


<<interface>> 
InvocationHandler 


request) invoke() 


InvocationHandler 
request() 


invoke() 


We need two 
of these. 


We ereate the 
proxy itself at 


runtime. 


Proxy OwnerInvocationHandler 


request() invoke() 


ie 


When a customer is viewing his own bean 


When a ¢ is viewi 
ustomer Is viewing, Someone else’s bean 


4 


NonOwnerlnvocationHandler 


Proxy 


request() invoke() 
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create an invocation handler 


Step one: creating Invocation Handlers 


We know we need to write two invocation handlers, one for the owner and one for the non-owner. But 
what are invocation handlers? Here’s the way to think about them: when a method call is made on the 
proxy, the proxy forwards that call to your invocation handler, but not by calling the invocation handler’s 
corresponding method. So, what does it call? Have a look at the InvocationHandler interface: 


<<interface>> 
OwnerInvocationHandler 


invoke() 


There’s only one method, invoke(), and no matter what methods get called on the proxy, the invoke() 
method is what gets called on the handler. Let’s see how this works: 


@) Let's say the setHotOrNotRating() 
method C called on the proxy. 


@ The proxy then 
Gee setHotOrNotRating (9) ; 


turns around and 
calls invoke() on the 
oS 


invoke (Object proxy, Method method, Object[] args) 


The Method ¢lass, part of the 


Here's how we reflection API, tells us what 
@) ve learnt ori ye “ ‘a method ef ae ie provy 
wnat | oO oO on e Kea ia its oe ame\/) method. 
with the request Subject. a“ 
and possibly 
forwards it on to 
the RealSubject. ——> return method.invoke(person, args) ; 


How does the 
handler decide? | 
ial tHere we invoke st in Only now we with the = 
‘ scene v WQuments- 
te 
object was passed to us in 
the invoke tall. 
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Creating Invocation Handlers continued... 


When invoke() is called by the proxy, how do you know what to do with the call? 
Typically, you'll examine the method that was called on the proxy and make 
decisions based on the method’s name and possibly its arguments. Let’s implement 


the OwnerInvocationHandler to see how this works: 


Invotationtandler is part of the java-lang-veflect 


package, so we need to import it. 


import java.lang.reflect.*; 


public class OwnerInvocationHandler implements 
PersonBean person; 


public OwnerInvocationHandler (PersonBean person) 
this.person = person; 


} 


public Object invoke (Object proxy, 
throws IllegalAccessException { 


try { 
if (method. getName () .startsWith (“get”) ) i 
return method.invoke(person, args); 
} else if (method.getName().equals (“setHotOrNotRating”) ) 
throw new IllegalAccessException (); 
} else if (method.getName().startsWith(“set”)) { a 
return method.invoke(person, args); 
} 
} catch (InvocationTargetException e) { 


e.printStackTrace(); 


} 
return null; This will happen if 
} the real subject 


hrows an exception. 
If any other method is called, 


we're just Going to ret, 
rather than take a Fane: a 


Method method, Object[] 


All invoeation handlers 


implement the 
Invoeationttandler 
interface. 


L 


InvocationHandler { 


{ ba 


— 


args) 


Because we dre 
the owner an 
other set method 
's tine and we go 
ahead and invoke 
it on the real 
subject. 


the proxy pattern 


Here’s the invoke 
method that gets 
called every time a 
method is invoked 
on the proxy. 


If the method is a 
getter, we go ahead 
and invoke it on the 
veal subject. 


Otherwise, if it is the 
setHotOr NotRating() 
method we disallow 
it by throwing a 
IllegalAecessException. 


you are here > 
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create your own invocation handler 


The NonOwnerInvocationHandler works just like the 
OwnerInvocationHandler except that it allows calls to set HotOrNotRating() 
and it disallows calls to any other set method. Go ahead and write this 
handler yourself: 
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Step two: creating the Proxy class and 
instantiating the Proxy object 


Now, all we have left is to dynamically create the proxy class and instantiate the proxy object. Let’s start by writing a 
method that takes a PersonBean and knows how to create an owner proxy for it. That is, we’re going to create the 
kind of proxy that forwards its method calls to the OwnerInvocationHandler. Here’s the code: 


This method takes a person os ia (the veal 
subject) and veturns a proxy tor it. Because the 
proxy has the same interface as the subject, we 
return a PersonBean. 


This code creates the 
proxy. Now this is some 


mighty ugly tode, so let's 
~ step through it tarefully. 
To treate a proxy we use the 
statie newProxy|nstance method 
on the Proxy elas... 


PersonBean getOwnerProxy(PersonBean person) { 


return (PersonBean) Proxy.newProxyInstance ( . " 
classloader 
person.getClass().getClassLoader(), << . yer if 
person.getClass().getInterfaces(), or our subject... 
new OwnerInvocationHandler (person) ); 


a Nd the set of interfaces the 


proxy needs to implement... 


We pass the real subject into the constructor 

of the invocation handler. [f you look back ..and an invocation handler, in this 
two pages you'll see this is how the handler gets case our Ownerlnvocationttandler. 
access to the real subject. 


oer your pencil While it is a little complicated, there isn’t much to creating a dynamic proxy. 


Why don’t you write getNonOwnerProxy(), which returns a proxy for the 
NonOwnerInvocationHandler: 


Take it further: can you write one method getProxy() that takes a 
handler and a person and returns a proxy that uses that handler? 
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find your match 


Testing the matchmaking service 


Let’s give the matchmaking service a test run and see how it controls access to the 


setter methods based on the proxy that is used. 


Main just eveates the test 


public class MatchMakingTestDrive { drive and ealls its drivel) 
// instance variables here method to get things going, 
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public void drive() { 


public static void main(String[] args) { 
MatchMakingTestDrive test = new MatchMakingTestDrive(); 


test.drive(); 


The constructor initializes 


eae our DB of people in the 
public MatchMakingTestDrive() { matchmaking, service. 


initializeDatabase(); 
Let’s retrieve a 


aa person from the DB 


and ereate an 


PersonBean joe = getPersonFromDatabase (“Joe Javabean”) ¢_—_ 

PersonBean ownerProxy = getOwnerProxy (joe) ; owner proxy: 
System.out.printin(“Name is he ownerProxy.getName () ) ; Call a getter 
ownerProxy.setInterests (“bowling, Go”); 

System.out.println(“Interests set from owner proxy”); and then a setter 


try { ae and then try to 
ownerProxy.setHotOrNotRating (10) ; change the rating, 
} catch (Exception e) { 
System.out.printlin(“Can’t set rating from owner proxy”); 


this shouldn't work! 
System.out.printin(“Rating is “ + ownerProxy.getHotOrNotRating()); 


€ Now ereate a 


PersonBean nonOwnerProxy = getNonOwnerProxy (joe); non-owner Proxy 


System.out.printin(“Name is “ + nonOwnerProxy.getName () ) ; and all a getter 
a. = followed by a 
nonOwnerProxy.setInterests (“bowling, Go”); 
setter 


} catch (Exception e) { 
System.out.printlin(“Can’t set interests from non owner Proxy”) 7 This shouldn't work! 

} 

nonOwnerProxy.setHotOrNotRating (3); 

System.out.printlin(“Rating set from non owner proxy”); Then try to set 

System.out.printin(“Rating is “ + nonOwnerProxy.getHotOrNotRating()); the rating 


// other methods like getOwnerProxy and getNonOwnerProxy here This should work! 
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the proxy pattern 
Running the code... 


File Edit Window Help Born2BDynamic 


Q 


% java MatchMakingTestDrive 


Name is Joe Javabean Our Owner proxy 


allows getting and 
Interests set from owner proxy setting, except for the 


Can’t set rating from owner proxy HotOrNot rating. 


Rating is 7 


Name is Joe Javabean Our NonOwner proxy 
allows getting only, but 
Can’t set interests from non owner proxy also allows ¢alls to set the 


Rating set from non owner proxy pee Nereus 
Rating is 5 
K— The new rating is the average of the previous rating, 7 

and the value set by the nonowner proxy, 3. 


% 
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q&a about 


+ So what exactly is the 
“dynamic” aspect of dynamic 
proxies? Is it that I’m instantiating 
the proxy and setting it to a handler 
at runtime? 


A: No, the proxy is dynamic 
because its class is created at runtime. 
Think about it: before your code runs 
there is no proxy class; it is created on 
demand from the set of interfaces you 
Pass it. 


- My InvocationHandler seems 
like a very strange proxy, it doesn’t 
implement any of the methods of 
the class it’s proxying. 


A: That is because the 


InvocationHandler isn’t a proxy — it is 
a class that the proxy dispatches to 
for handling method calls. The proxy 
itself is created dynamically at runtime 
by the static Proxy.newProxylnstance() 
method. 


Q: Is there any way to tell if a 
class is a Proxy class? 
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th oe « 
Dum > Questions 


> Yes. The Proxy class has a static 
method called isProxyClass(). Calling 
this method with a class will return 
true if the class is a dynamic proxy 
class. Other than that, the proxy class 
will act like any other class that imple- 
ments a particular set of interfaces. 


: Are there any restrictions on 
the types of interfaces I can pass into 
newProxylnstance()? 


A: Yes, there are a few. First, it is 
worth pointing out that we always 
pass newProxylnstance() an array of 
interfaces — only interfaces are allowed, 
no classes. The major restrictions are 
that all non-public interfaces need to 
be from the same package. You also 
can't have interfaces with clashing 
method names (that is, two interfaces 
with a method with the same 
signature). There are a few other minor 
nuances as well, so at some point you 
should take a look at the fine print on 
dynamic proxies in the javadoc. 


: Why are you using skeletons? 
I thought we got rid of those back in 
Java 1.2. 


A: You're right; we don’t need 

to actually generate skeletons. As 
of Java 1.2, the RMI runtime can 
dispatch the client calls directly to 
the remote service using reflection. 
But we like to show the skeleton, 
because conceptually it helps you to 
understand that there is something 
under the covers that’s making that 
communication between the client 
stub and the remote service happen. 


Q: | heard that in Java 5, | 
don’t even need to generate stubs 
anymore either. Is that true? 


A: It sure is. In Java 5, RMI and 
Dynamic Proxy got together and 

now stubs are generated dynamically 
using Dynamic Proxy. The remote 
object's stub is a java.lang.reflect.Proxy 
instance (with an invocation handler) 
that is automatically generated to 
handle all the details of getting the 
local method calls by the client to 

the remote object. So, now you don't 
have to use rmic at all; everything you 
need to get a client talking to a remote 
object is handled for you behind the 
scenes. 


the proxy pattern 


+9 


* 
WHS BOES WHAT? 


Match each pattern with its description: 


Pattern Description 


Decorator Wraps another object 
and provides a different 
interface to it 


Facade Wraps another object 
and provides additional 
behavior for it 


Wraps another object to 
control access to it 


Wraps a bunch of 
objectsto simplify their 
interface 
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the proxy zoo 


The Proxy Zoo 


Welcome to the Objectville Zoo! 


You now know about the remote, virtual and protection proxies, but 
out in the wild you’re going to see lots of mutations of this pattern. 
Over here in the Proxy corner of the zoo we’ve got a nice collection 
of wild proxy patterns that we’ve captured for your study. 


Our job isn’t done; we are sure you're going to see more variations of 
this pattern in the real world, so give us a hand in cataloging more 
proxies. Let’s take a look at the existing collection: 


“~ Habitat: often seen in the location 


aI 
Firewall Proxy of corporate firewall systems. 
controls access toa 


set of network 
resources, protecting 
the subject from “bad" clients. 


~ OS 


Help find a habitat 


Smart Reference Proxy 
provides additional actions 
whenever a subject is 
referenced, such as counting 
the number of references to 
an object. 


Caching Proxy provides EX 


Nemporany ‘stencge Tor Habitat: often seen in web server proxies as well 


results of operations 
that are eee It as content management and publishing systems. 


can also allow multiple clients to share 
the results to reduce computation or 
network latency. 
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i Seen hanging around J 

: favaS 

it soviie synthronized pi 

an ; 

Synchronization Proxy dictrbete’ set of objects in a 
provides safe access to €2 environment. 

a subject from multiple 

threads. 


Help find a habitat 7 —S Complexity Hiding Proxy 
hides the complexity of 


and controls access to a 
complex set of classes. 
This is sometimes called 

the Facade Proxy for obvious reasons. 
The Complexity Hiding Proxy differs 
from the Facade Pattern in that the 
proxy controls access, while the Facade 
Pattern just provides an alternative 
interface. 


Copy-On-Write Proxy 

controls the copying of 

an object by deferring 

the copying of an object = Habitat: seen in the vicinity of the 
until it is required by a Java 9’s CopyOnWritefvrayList 
client. This is a variant of 

the Virtual Proxy. 


Field Notes: please add your observations of other proxies in the wild here: 
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crossword puzzle 


RB 
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crossword puzzle before it ends? 


It’s been a LONG chapter. Why not unwind by doing a 


i 


FETE PT Pe 


10 


2 


| | 
| a 
ie) 
ra 
a a 


Lo 


Plt tf | 


Across 

1. Group of first CD cover displayed (two words) 
3. Proxy that stands in for expensive objects 

4. We took one of these to learn RMI 

7. Remote was used to implement 
the gumball machine monitor (two words) 

9. Software developer agent was being this kind 
of proxy 

11. In RMI, the object that takes the network 
requests on the service side 

14. Proxy that protects method calls from 
unauthorized callers 

15.A proxy class is created at runtime 
16. Place to learn about the many proxy variants 
17. Commonly used proxy for web services (two 
words) 

18. In RMI, the proxy is called this 

19. The CD viewer used this kind of proxy 
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SERRE 


PT Tt 


Pit tt | ft 


Down 

2. Java's dynamic proxy forwards all requests to 
this (two words) 

5. Group that did the album MCMXC A.D. 

6. This utility acts as a lookup service for RMI 

8. Why Elroy couldn't get dates 

10. Similar to proxy, but with a different purpose 
12. Objectville Matchmaking gimmick (three 
words) 

13. Our first mistake: the gumball machine 
reporting was not 


Tools for your Design Toolbox 


of 7 Your design toolbox is almost full; you’re prepared 
for almost any design problem that comes your way. 


OO Principles 


Encapsulate what varies: 


vt ran 
Favor composition ove! 


Program t inberkates 
ivapiement ations 


mheritance- 
not 


led, designs 
tC 
ctrve for ue Santer 


c 
ween 00) ; 
bert = [es extension 


Navid beroPeh 
een for modification - . a 
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end on 3! ee se 
er on tonevete C15 ie : a ‘ 
talk te Your Lyiends: a 
Orly 
Dont tall vs we ll tall yor 
on 
} elass chovld have only one reason 
ko chande- 
| . Our new pattern. 
00 Patterns . — 
S : se " representative Le 
C. | 
e 1 h e fl an-L- tk p ; re se 
¢ ee ; | 
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the proxy pattern 


The Proxy Pattern provides 
a representative for another 
object in order to control the 
client’s access to it. There 
are a number of ways it can 
manage that access. 


A Remote Proxy manages 
interaction between a client 
and a remote object. 


A Virtual Proxy controls access 
to an object that is expensive 
to instantiate. 


A Protection Proxy controls 
access to the methods of an 
object based on the caller. 


Many other variants of 

the Proxy Pattern exist 
including caching proxies, 
synchronization proxies, 
firewall proxies, copy-on-write 
proxies, and so on. 


Proxy is structurally similar to 
Decorator, but the two differ in 
their purpose. 


The Decorator Pattern adds 
behavior to an object, while a 
Proxy controls access. 


Java’s built-in support for Proxy 
can build a dynamic proxy 
class on demand and dispatch 
all calls on it to a handler of 
your choosing. 


Like any wrapper, proxies will 
increase the number of classes 
and objects in your designs. 
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exercise solutions 


at 


76 Exercise solutions 


The NonOwnerInvocationHandler works just like the 
OwnerInvocationHandler, except that it allows calls to setHotOrNotRating() 
and it disallows calls to any other set method. Go ahead and write this 
handler yourself: 


import java.lang.reflect.*; 


public class NonOwnerInvocationHandler implements InvocationHandler { 
PersonBean person; 


public NonOwnerInvocationHandler(PersonBean person) { 
this.person = person; 


public Object invoke (Object proxy, Method method, Object[] args) 
throws IllegalAccessException { 


try 
if (method. getName().startsWith(“get”)) { 

return method.invoke (person, args); 

lse if (method.getName().equals(“setHotOrNotRating”)) { 
return method.invoke (person, args); 

lse if (method.getName().startsWith(“set”)) { 

throw new IllegalAccessException (); 


} catch (InvocationTargetException e) { 
e.printStackTrace () ; 


} 


return null; 


Design Class 


Our ImageProxy class appears to have two states that are controlled 
by conditional statements. Can you think of another pattern that 
might clean up this code? How would you redesign ImageProxy? 


Use State Pattern: implement two states, ImageLoaded and ImageNotLoaded. Then put the code from 
the if statements into their respective states. Start in the ImageNotLoaded state and then transition to the 
ImageLoaded state once the Imagelcon had been retrieved. 
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SLB Exercise solutions 


G harpen your pencil 
While it is a little complicated, there isn’t much to creating a dynamic 
aN proxy. Why don’t you write getNonOwnerProxy(), which returns a 
proxy for the NonOwnerlInvocationHandler: 


PersonBean getNonOwnerProxy(PersonBean person) { 


return (PersonBean) Proxy.newProxyInstance ( 
person.getClass().getClassLoader(), 
person.getClass().getInterfaces(), 


new NonOwnerInvocationHandler (person) ); 
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ready-bake code: cd cover viewer 


The code for the CD Cover Viewer 


package headfirst.proxy.virtualproxy; 


import java.net.*; 

import java.awt.*; 

import java.awt.event.*; 

import javax.swing.*; 

import java.util.*; 

public class ImageProxyTestDrive { 
ImageComponent imageComponent; 
JFrame frame = new JFrame(“CD Cover Viewer”) ; 
JMenuBar menuBar; 
JMenu menu; 
Hashtable cds = new Hashtable(); 


public static void main (String[] args) throws Exception { 
ImageProxyTestDrive testDrive = new ImageProxyTestDrive(); 


public ImageProxyTestDrive() throws Exception{ 
cds.put (“Ambient: Music for Airports”,”http://images.amazon.com/images/P/ 
BO00003S2K.01.L2222222.4pgq”) ; 
cds.put (“Buddha Bar”, ”http://images.amazon.com/images/P/BOOOO9XBYK.01.LZZ22222Z. 


jpg"); 
cds.put (“Ima”, “http: //images.amazon.com/images/P/BO00005IRM.01.L2222222.jpg”) ; 
cds.put (“Karma”, “http://images.amazon.com/images/P/BOO0005DCB.01.LZ2222Z22.gif”); 
cds.put (“MCMXC A.D.”,”http://images.amazon.com/images/P/BOOO0002URV.01.LZZ22222Z. 
jpg"); 
cds.put (“Northern Exposure”,”http://images.amazon.com/images/P/BOOO003SFN.01. 


LZZZ2Z222Z.4pgq") ; 
cds.put (“Selected Ambient Works, Vol. 2”,”http://images.amazon.com/images/P/ 
BO00002MNZ.01.L22Z22222.jpg”) ; 
cds.put (“oliver”,”http://www.cs.yale.edu/homes/freeman-elisabeth/2004/9/Oliver | 


sm.jpg”); 


URL initialURL = new URL( (String) cds.get (“Selected Ambient Works, Vol. 2”)); 
menuBar = new JMenuBar(); 

menu = new JMenu(“Favorite CDs”); 

menuBar.add(menu) ; 

frame.setJMenuBar (menuBar) ; 
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for (Enumeration = cds.keys(); -hasMoreElements();) { 
String name = (String)e.nextElement (); 
JMenuItem menultem = new JMenultem(name) ; 
menu.add(menultem) ; 
menultem.addActionListener (new ActionListener() { 
public void actionPerformed(ActionEvent event) { 
imageComponent.setIcon(new ImageProxy (getCDUrl (event. getActionCom- 


mand()))); 
frame.repaint (); 


// set up frame and menus 


Icon icon = new ImageProxy(initialURL) ; 
imageComponent = new ImageComponent (icon) ; 
frame.getContentPane() .add(imageComponent) ; 
frame.setDefaultCloseOperation (JFrame.EXIT ON CLOS 
frame.setSize (800,600); 

frame.setVisible (true) ; 


Fl 
~ 


URL getCDUrl (String name) { 
try { 
return new URL( (String) cds.get (name) ) ; 
} catch (MalformedURLException e) { 
e.printStackTrace(); 
return null; 
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The code for the CD Cover Viewer, 
continued... 


package headfirst.proxy.virtualproxy; 


import java.net.*; 
import java.awt.*; 
import java.awt.event.*; 
import javax.swing.*; 


class ImageProxy implements Icon { 
ImageIcon imagelIcon; 
URL imageURL; 
Thread retrievalThread; 
boolean retrieving = false; 


public ImageProxy(URL url) { imageURL = url; } 


public int getIconWidth() { 


if (imageIcon != null) { 
return imageIcon.getIconWidth (); 
} else { 


return 800; 


public int getIconHeight() { 


if (imageIcon != null) { 
return imageIcon.getIconHeight (); 
} else { 


return 600; 


public void paintIcon(final Component c, Graphics g, int x, int y) { 


if (imageIcon != null) { 
imageIcon.paintIcon(c, g, xX, y); 
} else { 
g.drawString (“Loading CD cover, please wait...”, x+300, y+190); 
if (!retrieving) { 
retrieving = true; 
retrievalThread = new Thread(new Runnable() { 
public void run() { 
try { 


imageIcon = new ImageIcon(imageURL, “CD Cover”); 
c.repaint(); 
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} catch (Exception e) { 
e.printStackTrace (); 


})e 


retrievalThread.start(); 


package headfirst.proxy.virtualproxy; 


import java.awt.*; 
import javax.swing.*; 


class ImageComponent extends JComponent { 
private Icon icon; 


public ImageComponent (Icon icon) { 
this.icon = icon; 


public void setIcon(Icon icon) { 
this.icon = icon; 


public void paintComponent (Graphics g) { 
super.paintComponent (g) ; 
int w = icon.getIconWidth (); 
int h = icon.getIconHeight (); 
int x = (800 - w)/2; 
int y = (600 - h)/2; 
icon.paintIcon(this, g, x, y); 
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12 Compound Patterns 


Patterns + 


of Patterns * 


Who would have ever guessed that Patterns could work together? 
You've already witnessed the acrimonious Fireside Chats (and you haven't even seen the Pattern 
Death Match pages that the editor forced us to remove from the book*), so who would have thought 


patterns can actually get along well together? Well, believe it or not, some of the most powerful OO 
designs use several patterns together. Get ready to take your pattern skills to the next level; it’s time 
for compound patterns. 


* send us email for a copy. 
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Working together 


One of the best ways to use patterns is to get them out of the house so they 
can interact with other patterns. ‘The more you use patterns the more you’re 
going to see them showing up together in your designs. We have a special 
name for a set of patterns that work together in a design that can be applied 
over many problems: a compound pattern. ‘That’s right, we are now talking 
about patterns made of patterns! 


You'll find a lot of compound patterns in use in the real world. Now that 
you've got patterns in your brain, you'll see that they are really just patterns 
working together, and that makes them easier to understand. 


We're going to start this chapter by revisiting our friendly ducks in the 
SimUDuck duck simulator. It’s only fitting that the ducks should be here 
when we combine patterns; after all, they’ve been with us throughout the 
entire book and they’ve been good sports about taking part in lots of patterns. 
The ducks are going to help you understand how patterns can work together 
in the same solution. But just because we’ve combined some patterns doesn’t 
mean we have a solution that qualifies as a compound pattern. For that, it 
has to be a general purpose solution that can be applied to many problems. 
So, in the second half of the chapter we'll visit a real compound pattern: 
that’s right, Mr. Model-View-Controller himself: If you haven’t heard of 
him, you will, and you'll find this compound pattern 1s one of the most 
powerful patterns in your design toolbox. 


Patterns are often used together and 
combined within the same design solution. 


A compound pattern combines two or 
more patterns into a solution that solves a 


recurring or general problem. 
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Duck reunion 


As you've already heard, we’re going to get to work with the ducks again. This time the ducks 
are going to show you how patterns can coexist and even cooperate within the same solution. 


We’re going to rebuild our duck simulator from scratch and give it some interesting capabilities 
by using a bunch of patterns. Okay, let’s get started... 


0) 


First, we'll create a Quackable interface. 


Like we said, we're starting from scratch. This time around, the Ducks are 
going to implement a Quackable interface. That way we'll know what things 
in the simulator can quack() - like Mallard Ducks, Redhead Ducks, Duck 
Calls, and we might even see the Rubber Duck sneak back in. 


public interface Quackable { nie 
public void quack(); Quackables on} 
} eK Hit Lind well: 


Now, some Ducks that implement Quackable 


What good is an interface without some classes to implement it? Time to 
create some concrete ducks (but not the “lawn art" kind, if you know what 


we mean). 
—_ - standard 


Mallard duck. 
public class MallardDuck implements Quackable { 


public void quack() { 
System.out.printlin (“Quack”) ; 
} 


public class RedheadDuck implements Quackable { 
public void quack() { 
System.out.printlin (“Quack”) ; 


a. We've got to have some variation 
of species if we want this to be an 


interesting simulator. 


_ ar, {es ra 
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adding more ducks 


This wouldn't be much fun if we didn't add other kinds of Ducks too. 


Remember last time? We had duck calls (those things hunters use, they 
are definitely quackable) and rubber ducks. 


public class DuckCall implements Quackable { 
public void quack() { 


System.out. intin (“Kwak”) ; ) 
ystem.out.print1n (“Kwak”) A DuekCall that quacks but doesn't 


: sound quite like the veal thing, 


public class RubberDuck implements Quackable { 
public void quack() { 


System.out.printin(“Squeak”) ; A RubberDuck that makes a 


squeak when it quacks. 


Okay, we've got our ducks; now all we need is a simulator. 
Let's cook up a simulator that creates a few ducks and makes sure their 


uackers are working... 
| a, Here's our main method to 


get everything going, 
public class DuckSimulator { 
a ne de nieve gaia ce = oy coe We eveate a simulator 
uckSimulator simulator = new DuckSimulator(); aca Bren eall its 


simulator.simulate(); a simulate( method. 


void simulate() { 
Quackable mallardDuck = new MallardDuck(); Scows ducks, 
Quackable redheadDuck = new RedheadDuck(); We nee a eath 
Quackable duckCall = new DuckCall(); we create one 
Quackable rubberDuck = new RubberDuck(); Quackable.-- 


so here 


System.out.println(“\nDuck Simulator”) ; 


simulate 
simulate 
simulate 
simulate 


mallardDuck) ; 
redheadDuck) ; _. then we simulate 


duckCall) ; a _eath one. 


rubberDuck) ; 


Here we overload the simulate 


} 
a method {o simulate just one duck. 
void simulate (Quackable duck) { 


duck. quack (); 
} 
} Ry Here we let polymorphism do its magi¢: no 
matter what kind of Quackable gets passed in, 


the simulate() method asks it to quack. 
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Not too exei 
haven’ adde 


ti 
™9 yet, but we 


Patterns! % java DuckSimulator 


Duck Simulator 
Quack 

Quack 

Kwak 

Squeak 


% 


They all implement the same Quackable 
interface, but their implementations 
allow them to quack in their own way: 


It looks like everything is working: so far, so good. 


@) When ducks are around, geese can't be far. 


Where there is one waterfowl, there are probably two. Here's a Goose 
class that has been hanging around the simulator. 


public class Goose { 
public void honk() { xm _ & Goose is a honker, 
System. out.printin (“Honk”) ; not a quacker. 
} 


BOs RAW 
Let’s say we wanted to be able to use a Goose anywhere we'd want to use a Duck. After all, geese 
make noise; geese fly; geese swim. Why can’t we have Geese in the simulator? 


What pattern would allow Geese to easily intermingle with Ducks? 
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© We need a goose adapter. 


Our simulator expects to see Quackable interfaces. Since geese 
aren't quackers (they're honkers), we can use an adapter to adapt 


a goose to a duck. 
LOY ee an Adapter 


r Lace, 
public class GooseAdapter implements Quackable { implements the target inka 9 , 
Goose goose; which in this Case 1s Quvackable. 
public GooseAdapter (Goose goose) { e The constructor takes the 
this.goose = goose; goose we are Qoind, to adapt. 
} 
pu vee eee ety an When quack is called, the call is delegated 


goose.honk(); to the goose’s honk() method. 


© Now geese should be able to play in the simulator, too. 


All we need to do is create a Goose, wrap it in an adapter that 
implements Quackable, and we should be good to go. 


public class DuckSimulator { 
public static void main(String[] args) { 
DuckSimulator simulator = new DuckSimulator(); 
simulator.simulate(); 


void simulate() { We make a Goose that atts like 
Quackable mallardDuck = new MallardDuck(); an a Duck by wiraPPind the Goose 
Quackable redheadDuck = new RedheadDuck () ; in the GooseAdapter: 
Quackable duckCall = new DuckCall(); 
Quackable rubberDuck = new RubberDuck() ; 
Quackable gooseDuck = new GooseAdapter (new Goose()); 


System.out.println(“\nDuck Simulator: With Goose Adapter”); 


simulate (mallardDuck) ; i" 
simulate (redheadDuck) ; Once the Goose is wrapped, we Can trea 


( 

( 
simulate (duckCall) ; a it just like other duck Quackables. 
simulate (rubberDuck) ; 

( 


simulate (gooseDuck) ; 


void simulate (Quackable duck) { 
duck. quack (); 
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Now let's give this a quick run.... 

This time when we run the simulator, the list of objects passed 
to the simulate() method includes a Goose wrapped in a duck 
adapter. The result? We should see some honking! 


File Edit Window Help GoldenEggs 


% java DuckSimulator 


Duck Simulator: With Goose Adapter 
Quack 
Quack 

There’s the Goose! Now the Kwak 

Goose can quack with the Squeak 


vest of the Ducks. _, Honk 


Quackology 


Quackologists are fascinated by all aspects of Quackable behavior. One 
thing Quackologists have always wanted to study is the total number of 
quacks made by a flock of ducks. 


How can we add the ability to count duck quacks without having to 
change the duck classes? 


Can you think of a pattern that would help? 


J. Brewer, f 


Park Ranger and 
Quackologist 
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We're going to make those Quackologists happy and give 
them some quack counts. 
How? Let's create a decorator that gives the ducks some new 


behavior (the behavior of counting) by wrapping them with a 
decorator object. We won't have to change the Duck code at all. 


Like with Adapter, we need to 


QuatkCounter is a decorator implement the target interface. 
We've got an instance variable 
to hold on to the quacker we've 
public class QuackCounter implements Quackable { decorating, 
Quackable duck; dares abe i 
static int numberOfQuacks; ) oh 
quacks, so well use a stati 


vari 
public QuackCounter (Quackable duck) { riable to keep track. 


this.duck = duck; 
| We get the reference to the 


Quackable we're decorating in 


public void quack() { the constructor. 
duck. quack (); Jst—_ m . 
ate ee he) Le is called, we delegate the call to 
udlKable we 


} ve decorating... 


public static int getQuacks() { ~ then we inérease the number at 
return numberOfQuacks; quacks. 


. \ 


We've adding one other method 
to the detorator. This static 
method just returns the number 
of quacks that have ot¢urred in 
all Quackables. 
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@) We need to update the simulator to create decorated ducks. 


Now, we must wrap each Quackable object we instantiate in a 
QuackCounter decorator. If we don't, we'll have ducks running 
around making uncounted quacks. 


public class DuckSimulator { 
public static void main (String[] args) { Eath time we eieiies 
DuckSimulator simulator = new DuckSimulator(); Ousek bl 
simulator.simulate(); able, we wrap it 
} with a new decorator. 


void simulate() { 
Quackable mallardDuck = new QuackCounter(new MallardDuck()); 
Quackable redheadDuck = new QuackCounter (new RedheadDuck()); 
Quackable duckCall = new QuackCounter(new DuckCall()); 
Quackable rubberDuck = new QuackCounter (new RubberDuck()); 
Quackable gooseDuck = new GooseAdapter (new Goose()); 


System.out.println(“\nDuck Simulator: With Decorator”) ; 


The park ranger told us he didn’t 


simulate (mallardDuck) ; want to count geese honks, so we 
simulate (redheadDuck) ; don’t decorate it. 
simulate (duckCall); 
simulate (rubberDuck) ; m eS wh 
eres where We 
( — 


simulate (gooseDuck) ; 


gather the quacking 


; wv the 
System.out.printin(“The ducks quacked “ + behavior 
QuackCounter.getQuacks() + “ times”); Quackologis ; 


void simulate (Quackable duck) { aaa Nothing changes here; the decorated 
duck. quack () ; abjetts ave still Quatkables. 


File Edit Window Help DecoratedEggs 


% java DuckSimulator 


Duck Simulator: With Decorator 
Here's the 7 2 Quack 
output Quack 


Kwak 


Squeak 
Honk 
4 quacks were counted 


’ 
Remember, Wer 


not counting, geese: 
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This quack counting is 
great. We're learning things we 
never knew about the little quackers. 
But we're finding that too many 
quacks aren't being counted. Can 
you help? 


You have to decorate objects 

to get decorated behavior. 

He’s right, that’s the problem with wrapping objects: 
you have to make sure they get wrapped or they don’t 
get the decorated behavior. 


Why don’t we take the creation of ducks and localize 
it in one place; in other words, let’s take the duck 
creation and decorating and encapsulate it. 


What pattern does that sound like? 


We need a factory to produce ducks! 


Okay, we need some quality control to make sure our ducks get wrapped. 
We're going to build an entire factory just to produce them. The factory 
should produce a family of products that consists of different types of 
ducks, so we're going to use the Abstract Factory Pattern. 


Let's start with the definition of the AbstractDuckFactory: [ae 
We're defining an abstract tactory 
—_— that subclasses will implement: to 
eveate different families. 
public abstract class AbstractDuckFactory { 
public abstract Quackable createMallardDuck () ; 
public abstract Quackable createRedheadDuck () ; 


public abstract Quackable createDuckCall(); 
public abstract Quackable createRubberDuck () ; 


Each method ereates one kind of duck. 
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Let's start by creating a factory that creates ducks without decorators, 
just to get the hang of the factory: 


public class DuckFactory extends AbstractDuckFactory { 


public Quackable createMallardDuck() { DuekFactory extends the 
return new MallardDuck() ; abstract factory. 
} 
public Quackable createRedheadDuck() { Eath method ereates a product: 
return new RedheadDuck(); ‘ articular kind A Quackable. 
} y + is unknown to 
The attual product | 


the simulator — it just knows it's 


public Quackable createDuckCall() { 
getting a Quackable. 


return new DuckCall (); 


} 


public Quackable createRubberDuck() { 
return new RubberDuck () ; 


} 


Now let's create the factory we really want, the CountingDuckFactory: CountingDuekFattory 
also extends the 
abstract factory. 


public class CountingDuckFactory extends AbstractDuckFactory { 


public Quackable createMallardDuck() { 


return new QuackCounter (new MallardDuck()); Each method wraps the 
} Quackable with the quack 
counting decorator. The 
public Quackable createRedheadDuck() { simulator will never know 
return new QuackCounter (new RedheadDuck () ) ; the difference; it just 
} gets back a Quackable. 


But now our rangers Can 
be sure that all quacks are 
being, counted. 


public Quackable createDuckCall() { 
return new QuackCounter (new DuckCall()); 


} 


public Quackable createRubberDuck() { 
return new QuackCounter (new RubberDuck ()) ; 


} 
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@ Let's set up the simulator to use the factory. 


Remember how Abstract Factory works? We create a polymorphic method 
that takes a factory and uses it to create objects. By passing in different 
factories, we get to use different product families in the method. 


We're going to alter the simulate() method so that it takes a factory and 
uses it to create ducks. 


First we ereate 
he factory 
‘ : 
eve 9019, 
public class DuckSimulator { ee wn 
public static void main(String[] args) { to Pas tate) 
DuckSimulator simulator = new DuckSimulator(); the simu 


AbstractDuckFactory duckFactory = new CountingDuckFactory(); method: 


simulator.simulate (duckFactory) ; eo ee 


void simulate (AbstractDuckFactory duckFactory) { The simulate() 
Quackable mallardDuck = duckFactory.createMallardDuck (); method takes an 
Quackable redheadDuck = duckFactory.createRedheadDuck () ; Abstract DuekFactory 
Quackable duckCall = duckFactory.createDuckCall(); and uses it to create 
Quackable rubberDuck = duckFactory.createRubberDuck () ; ducks rather than 
Quackable gooseDuck = new GooseAdapter (new Goose()); instantiating Een 


directly. 
System.out.println(“\nDuck Simulator: With Abstract Factory”); Y 


simulate (mallardDuck) ; 
simulate (redheadDuck) ; 
simulate (duckCall); 
( 
( 


simulate (rubberDuck) ; oe 
simulate (gooseDuck) ; 


Nothing changes here! 


System.out.printlin(“The ducks quacked “ + LZ Caneel wade 
QuackCounter.getQuacks() + 
“ times”); 


void simulate (Quackable duck) { 
duck. quack (); 
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Here’s the output using the factory. 


File Edit Window Help EggFactory 


a. % java DuckSimulator 


but Duck Simulator: With Abstract Factory 
Quack 


nis Lime Wi we, 
sae the ducks are guac 
\\ decorated because a 
r he 
we are using, on 
attory- 
_ 4 quacks were counted 


% 


Ge sharpen your pencil 
een yep 


We're still directly instantiating Geese by relying on concrete classes. Can you write 
an Abstract Factory for Geese? How should it handle creating “goose ducks”? 
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It's getting a little difficult 
to manage all these different ducks 
separately. Is there any way you can 
help us manage ducks as a whole, and 
perhaps even allow us to manage a few 
duck “families” that we'd like to keep 
track of? 


Ah, he wants to manage a 
flock of ducks. 


Here’s another good question from Ranger Brewer: 
Why are we managing ducks individually? 


Quackable mallardDuck = duckFactory.createMallardDuck () ; 


F Quackable redheadDuck = duckFactory.createRedheadDuck () ; 
This isn't very Pi Quackable duckCall = duckFactory.createDuckCall (); 
manageable! Quackable rubberDuck = duckFactory.createRubberDuck () ; 
See Quackable gooseDuck = new GooseAdapter (new Goose()); 


simulate (mallardDuck) ; 
simulate (redheadDuck) ; 
simulate (duckCall); 
simulate (rubberDuck) ; 
simulate (gooseDuck) ; 


What we need is a way to talk about collections of 
ducks and even sub-collections of ducks (to deal with 
the family request from Ranger Brewer). It would 
also be nice if we could apply operations across the 
whole set of ducks. 


What pattern can help us? 
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2) Let's create a flock of ducks (well, actually a flock of Quackables). 


Remember the Composite Pattern that allows us to treat a collection of 
objects in the same way as individual objects? What better composite 
than a flock of Quackables! 


Let's step through how this is going to work: 


Remember, the composite needs to implement 
the same interface as the leaf elements. Our 
leaf elements are Quackables. 


We've using an ArrayList inside 
each Flock to hold the Quackables 
that belong to the Flock. 


public class Flock implements Quackable { 
ArrayList quackers = new ArrayList (); a 


public void add(Quackable quacker) { 


quackers.add(quacker) ; he The add() method adds a 


: Quatkable to the Flock. 


public void quack() { 
Iterator iterator = quackers.iterator(); 
while (iterator.hasNext()) { 
Quackable quacker = (Quackable)iterator.next(); 
quacker. quack (); 


} 
Now for the quack() me hod — after all, the Flock is a Quackable a 
The quack method in Flock needs to work over the entire Flock. Here 


we iterate through the ArrayList and call quack() on each element. 


Code Up Close 
Did you notice that we tried to sneak a Design Pattern by 
you without mentioning it? 


public void quack() { ie There it is! The [terator 
Iterator iterator = quackers.iterator() ; ee Pattern at work! 
while (iterator.hasNext()) { 


Quackable quacker = (Quackable) iterator.next() ; 
quacker. quack () ; 
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(©) Now we need to alter the simulator. 


Our composite is ready; we just need some code to round up the 
ducks into the composite structure. 


public class DuckSimulator { 


// main method here Create all the 
Quackables, just 
void simulate (AbstractDuckFactory duckFactory) { like before. 
Quackable redheadDuck = duckFactory.createRedheadDuck () ; 
Quackable duckCall = duckFactory.createDuckCall (); 
Quackable rubberDuck = duckFactory.createRubberDuck (); 
Quackable gooseDuck = new GooseAdapter (new Goose()); 
System.out.println(“\nDuck Simulator: With Composite - Flocks”); 
Flock flockOfDucks = new Flock(); First we create a Flock, and 
load it up with Quackables. 
flockOfDucks .add(redheadDuck) ; 
flockOfDucks .add (duckCall) ; a 
flockO£Ducks.add(rubberDuck) ; Then we create a new 


flockOfDucks.add(gooseDuck) ; ee Flock of Mallards. 


Flock flockOfMallards = new Flock(); 


1 _ Here we've creating 
; a little family of 


Quackable mallardOne = duckFactory.createMallardDuck (); 
mallards... 


() 
Quackable mallardTwo = duckFactory.createMallardDuck (); 
Quackable mallardThree = duckFactory.createMallardDuck () ; 
Quackable mallardFour = duckFactory.createMallardDuck (); 


flockOfMallards.add(mallardOne) ; A and adding them to the 


flockOfMallards.add(mallardTwo) ; Flock of mallards. 
flockOfMallards.add(mallardThree) ; Thexaeadd the Fie of 


flockOfMallards.add(mallardFour) ; 2 
mallards to the main flock. 
flockOfDucks.add (flockOfMallards) ; 


System.out.printin(“\nDuck Simulator: Whole Plook SimulLstiansd sut the entire Flock! 
simulate (flockOfDucks) ; 


System.out.printin(“\nDuck Simulator: Mal gard Flock $4 ulation’); ' 
simulate (flockOfMallards) ; eh lets just test lt the mallard’s Flock 


System.out.println(“\nThe ducks quacked “ + 


QuackCounter.getQuacks (),+ ; ks 
Wy pasate ee Finally, let's give the 
} Quackologist the data. 
void simulate (Quackableduck) { 
duck. quack (); We, Nothing needs to change here, a Flock is a Quackable! 


} 
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Let's give it a spin... 


File Edit Window Help FlockADuck 
% java DuckSimulator 

Duck Simulator: With Composite - Flocks 

Duck Simulator: Whole Flock Simulation 

Quack 
Kwak 
Squeak 
Honk 
Quack 
Quack 
Quack 
Quack 


Here's the first flock. 


Duck Simulator: Mallard Flock a Been 

Quack , ae And now the m : 

Quack The data looks 
Quack good (remember 
Quack Lhe goose doesn t 
et counted). 
The ducks quacked 11 times 9 


Safety versus transparency 


You might remember that in the Composite Pattern chapter the composites (the Menus) and the leaf nodes 
(the Menultems) had the same exact set of methods, including the add() method. Because they had the 
same set of methods, we could call methods on Menultems that didn’t really make sense (like trying to add 
something to a Menultem by calling add()). The benefit of this was that the distinction between leaves and 
composites was transparent: the client didn’t have to know whether it was dealing with a leaf or a composite; 
it just called the same methods on both. 


Here, we've decided to keep the composite’s child maintenance methods separate from the leaf nodes: that 
is, only Flocks have the add() method. We know it doesn’t make sense to try to add something to a Duck, 
and in this implementation, you can’t. You can only add() to a Flock. So this design is safer — you can’t call 
methods that don’t make sense on components — but it’s less transparent. Now the client has to know that a 
Quackable is a Flock in order to add Quackables to it. 


As always, there are trade-offs when you do OO design and you need to consider them as you create your 
own composites. 
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The Composite is working 
great! Thanks! Now we have the 
opposite request: we also need to 
track individual ducks. Can you give 
us a way to keep track of individual 
duck quacking in real time? 


Can you say “observer?’ 

It sounds like the Quackologist would like to observe individual 
duck behavior. That leads us right to a pattern made for observing 
the behavior of objects: the Observer Pattern. 


First we need an Observable interface. 


Remember that an Observable is the object being observed. An Observable 
needs methods for registering and notifying observers. We could also have 
a method for removing observers, but we'll keep the implementation simple 
here and leave that out. 


QuackObservable is the interface 


that Quackables should implement 
if they want to be observed. 


public interface QuackObservable { 
public void registerObserver (Observer observer) ; 
public void notifyObservers(); 


It has a method for reaisteri 
} s) ng, 
Naw Observers. Any object implementing 


the Observer interface can listen 
It also has a method for to quacks. We'll define the Observer 
notifying the observers. interface in a set. 


Now we need to make sure all Quackables implement this interface... 


public interface Quackable extends QuackObservable { 


public void quack(); 
| ‘ 
So, we extend the Quackable 


interface with Quack Observer. 
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Stop looking at 
me. You're making 


me nervous! 
Now, we need to make sure all the concrete 


classes that implement Quackable can handle 


being a QuackObservable. o) 

We could approach this by implementing registration and 
notification in each and every class (like we did in Chapter 

2). But we're going to do it a little differently this time: a. » 
we're going to encapsulate the registration and notification 


code in another class, call it Observable, and compose it 
with a QuackObservable. That way we only write the real 
code once and the QuackObservable just needs enough 
code to delegate to the helper class Observable. 


Let's start with the Observable helper class... 
QuackObserverable 


Observable implements all the severe 
a Quatkable needs to be an observable. We 
cust need to plug it into a class and have 
Lhat class delegate to Observable. 


Observable must implement QuackObservable 
because these are the same method calls 
that are going to be delegated to it. 


In the tonstructor we get 
passed the QuatkObservable 
public class Observable implements QuackObservable { tial i using Lis object i 
ArrayList observers = 


new ArrayList (); manage its observable behavior. 
QuackObservable duck; ee Rat ast tie ratity0) method 
e that when a 


) 
- youll se 
public Observable (QuackObservable duck) { ie Ye ee 
this.duck = duck; vstiky Hs 
| this object along, so that the 
observer knows which object is 
public void registerObserver (Observer observer) { quacking, 


observers.add (observer) ; 
} c - tere’s the code for 


registering an observer. 


public void notifyObservers() { 
Iterator iterator = observers.iterator(); 
while (iterator.hasNext()) { 
Observer observer = (Observer) iterator.next(); 


observer.update (duck) ; 


} And the code for doing 
} _ 


the noti fieati ons. 


Now let’s see how a Quackable lass uses this helper... 
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Integrate the helper Observable with the Quackable classes. 


This shouldn't be too bad. All we need to do is make sure the Quackable classes 
are composed with an Observable and that they know how to delegate to it. After 
that, they're ready to be Observables. Here's the implementation of MallardDuck; 
the other ducks are the same. 


public class MallardDuck implements Quackable { Each Quackable has an 


VRS Nah Per Up eee aunee aa Observable instance variable. 


public MallardDuck() { 
observable = new Observable (this) ; 


In the Constructor, we create an 
a Observable and pass it a reference 


} to the MallardDuck object. 


public void quack() { 
System.out.printlin (“Quack”) ; When we quack, we 


notifyObservers(); ——— need to let the 


observers know about it. 


} 


public void registerObserver (Observer observer) { 
observable. registerObserver (observer) ; 


} 


public void notifyObservers() { 
observable.notifyObservers () ; 


Here’s our two QuackObservable 
T——~ methods. Notice that we jst 
delegate to the helper. 


Ge sharpen your pencil 
Saal 


We haven't changed the implementation of one Quackable, the QuackCounter 
decorator. We need to make it an Observable too. Why don’t you write that one: 
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We're almost there! We just need to work on the Observer side 
of the pattern. 


We've implemented everything we need for the Observables; now we 
need some Observers. We'll start with the Observer interface: 


The Observer interface just has 
one method, update(), which 


iS Passed the QuackOb 
that is quacking, silica 


public interface Observer { 
public void update (QuackObservable duck) ; 


} 


Now we need an Observer: where are 
those Quackologists?! 


We need to implement the Observable interface or else 
we won't be able to register with a QuackObservable. 


\ 


public class Quackologist implements Observer { 


public void update (QuackObservable duck) { 
System.out.printlin(“Quackologist: “ + duck + “ just quacked.”); 


Z s) 


The Quackologist is 
method, update() 
Quackable that j 


imple; it just has one 
) which Prints out the 
ust quacked. 
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Ge sharpen your pencil 
Sal 


What if a Quackologist wants to observe an entire flock? What does that mean 
anyway? Think about it like this: if we observe a composite, then we’re observing 
everything in the composite. So, when you register with a flock, the flock 
composite makes sure you get registered with all its children (sorry, all its little 
quackers), which may include other flocks. 


Go ahead and write the Flock observer code before we go any further... 
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We're ready to observe. Let's update the 
simulator and give it a try: 


public class DuckSimulator { 
public static void main(String[] args) { 
DuckSimulator simulator = new DuckSimulator(); 
AbstractDuckFactory duckFactory = new CountingDuckFactory(); 


simulator.simulate(duckFactory) ; 


void simulate (AbstractDuckFactory duckFactory) { 
// create duck factories and ducks here 
// create flocks here 
System.out.println(“\nDuck Simulator: With Observer”) ; 


All we do here is eveate a 


Quackologist quackologist = new Quackologist(); Quackoloaist and set him as 
flockOfDucks.registerObserver (quackologist) ; an observer of the flock. 


simulate (flockOfDucks) ; o™\ 


System.out.println(“\nThe ducks quacked “ + 


This time we'll we 


QuackCounter.getQuacks() + Just simulate the 
“ times”); entire flock. 

} 

void simulate (Quackable duck) { Let’s give it a try and 


duck. quack (); see how it works! 
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the duck finale 


This is the big finale. Five, no, six patterns have come together to create 


this amazing Duck Simulator. Without further ado, we present the 


DuckSimulator! 


File Edit Window Help DucksAreEverywhere 


% java DuckSimulator 
Duck Simulator: With Observer 


Quack 


After each quack, 
no matter what 


Quackologist: Redhead Duck just quacked. pee kind of quack 
it was, the 
observer gets a 
notification. 


Kwak 
Quackologist: 
Squeak 
Quackologist: 
Honk 
Quackologist: 
Quack 
Quackologist: 
Quack 
Quackologist: 
Quack 
Quackologist: 
Quack 
Quackologist: 


% 


> So this was a compound pattern? 


A: No, this was just a set of patterns 
working together. A compound pattern is a 
set of a few patterns that are combined to 
solve a general problem. We're just about 
to take a look at the Model-View-Controller 
compound pattern; it’s a collection of a few 
patterns that has been used over and over in 
many design solutions. 
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Duck Call just quacked. 


Rubber Duck just quacked. 


Mallard Duck just quacked. 
Mallard Duck just quacked. 
Mallard Duck just quacked. 


Mallard Duck just quacked. 
The Ducks quacked 7 times. 
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Dumb Questions 


Q: So the real beauty of Design 
Patterns is that | can take a problem, and 
start applying patterns to it until | have a 
solution. Right? 


A: Wrong. We went through this 
exercise with Ducks to show you how 
patterns can work together. You’d never 
actually want to approach a design like we 
just did. In fact, there may be solutions to 
parts of the duck simulator for which some 
of these patterns were big time overkill. 


eae 


Goose pretending to be a Duck just quacked. 


And the 
quackologist still 
gets his Counts. 


Sometimes just using good OO design 
principles can solve a problem well enough 
on its own. 


We're going to talk more about this in the 
next chapter, but you only want to apply 
patterns when and where they make 
sense. You never want to start out with the 
intention of using patterns just for the sake 
of it. You should consider the design of the 
DuckSimulator to be forced and artificial. 
But hey, it was fun and gave us a good 
idea of how several patterns can fit into a 
solution. 


compound patterns 


What did we do? 


We started with a bunch of Quackables... 


A goose came along and wanted to act like a Quackable too. Sowe 
used the Adapter Pattern to adapt the goose to a Quackable. Now, you can call quack() on 
a goose wrapped in the adapter and it will honk! 


Then, the Quackologists decided they wanted to count quacks. So we 
used the Decorator Pattern to add a QuackCounter decorator that keeps track of the number 
of times quack() is called, and then delegates the quack to the Quackable it’s wrapping. 


But the Quackologists were worried they’d forget to add the 
QuackCounter decorator. So we used the Abstract Factory Pattern to create ducks 
for them. Now, whenever they want a duck, they ask the factory for one, and it hands back 
a decorated duck. (And don't forget, they can also use another duck factory if they want an 
un-decorated duck!) 


We had management problems keeping track of all those ducks and 
geese and quackables. So we used the Composite Pattern to group quackables 
into Flocks. The pattern also allows the quackologist to create sub-Flocks to manage duck 
families. We used the /terator Pattern in our implementation by using java.util’s iterator in 
ArrayList. 


The Quackologists also wanted to be notified when any quackable 
quacked. So we used the Observer Pattern to let the Quackologists register as Quackable 
Observers. Now they're notified every time any Quackable quacks. We used iterator again 
in this implementation. The Quackologists can even use the Observer Pattern with their 
composites. 


That was quite a Design Pattern 
workout. You should study the 
class diagram on the next page 
and then take a relaxing break before 
continuing on with the Model-View- 
Controller. 
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duck’s eye view 


A. Bird's duck’s eye view: the class diagram 


We've packed a lot of patterns into one small duck simulator! Here’s the big picture of what we did: 


DuckSimulator 
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The DuekSimula 


tor uses a faetory to eveate Ducks. 


L 


AbstractDuckFactory 


createMallardDuck 


) 


createRedheadDuck(, 


createDuckCall() 
createRubberDuck() 


/ 


DuckFactory 


CountingDuckFactory 


createMallardDuck() 
createRedheadDuck() 
createDuckCall() 

createRubberDuck() 


lf a Class mtn \ 
Observer, that 


createMallardDuck() 
createRedheadDuck() 
createDuckCall() 

createRubberDuck() 


Here are two different 
factories that produce 
he same Lamil 
ear ine i ae ee 
tveates ducks, and the 
CountingDuckFactory 
treates Ducks wrapped in 
QuackCounter decorators. 


means it can observe 
Quackables, and will 


<<interface>> 
Observer 


be notified whenever 
4 Quackable quacks. 


update(QuackObservable) 


Quackologist 


update(QuackObservable) 


behavior to Quackables. 


The QuackObservable interface 
wes us a set of methods that 


avy Observable must implement: 


compound patterns 


Each Quackable has an 


<<interface>> instance of Observable 
Quackable is the inter he QuackObservable to keep track of their 
that all Classes that have registerObserver(Observer) observers and notify them 
qvacking behavior implement. notifyObservers() when the Quackable quacks. 
Nay a 
-TErrrrrrrrecerrererrereerrreeri ey | Observable 
5 <<interface>> ArrayList observers 
Quackable QuackObservable duck 
wen) registerObserver(Observer) 
‘ notifyObservers() 
MallardDuck } bee GooseAdapter 
q RedheadDuck l Goose goose 
reg 
oi DuckCall l ques) This Adapter... 
aI te registerObserver(Observer) 
HE RubberDuck notifyObservers() << 
re 
nd quack() 
registerObserver(Observer) fo: / vvrsrerrsee0+ Flock 
heaters ArrayList ducks 
J add(Quackable) 
. quack() - and this 
We have two kinds of registerObserver(Observer) Composite... 
Quackables: ducks and notifyObservers() y 
other things that want 
Quackable behavior: like the EX cans Giackeointer 
GooseAdapter, which wraps 2 ounte 
Goose and makes it look like Quackable duck «and Bee 
a Quackable; Floek, which is getQuacks() Detorator 
a Quackable Composite, and aed all act like 
ns hich a dds registerObserver(Observer) kabl | 
QuackCounter Ww noliiohaeniat Quackables! 
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the model view controller song 


The King of Compound Patterns 


If Elvis were a compound pattern, his name would be Model-View-Controller, 


and he'd he singing a little song like this... 


Model, View, Controller 
Lyries and musi¢ by James Dempsey. 


MVC’s a paradiom for factoring Your code 
into funetional segments, so Your brain does not explode. 


To achieve reusability, you gotta keep those boundaries 
clean 


Model on the one side, View on the other, the 
Controller’s in between. 


View 


Creamy 


ntroller 
a 


a Model 


Model View, it’s got three layers like Oreos do 
Model View Controller 
Model View, Model View, Model View Controller 


Model objects represent your application's raison d'etre 
Custom objects that contain data, logic, and et cetera 
You ereate custom classes, in Your app’s problem domain 
you an Choose to reuse them with all the views 

but the model objects stay the same. 


Chanter 19 
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You can model a throttle and a manifold 
Model the toddle of a two Year old 
Model a bottle of fine Chardonnay 
Model all the glottal stops people say 
Model the coddling of boiling eggs 

You can model the waddle in Hexley’s legs 


Model View, You Can model all the models that pose foy 
GQ 


Model View Controller 

Go doe 
View objets tend to be controls used to display and edit 
Cotoa’s got a lot of those, well written to its credit. 
Take an NSTextView, hand it any old Unicode string 
The user ¢an interact with it, it can hold most anything 
But the view don’t know about the Model 


That string could be a phone number or the works of 
Aristotle 


Keep the coupling loose 


5 Java! 


and so achieve a massive level of reuse 


Model View, all rendered very nicely in Aqua blue 
Model View Controller 


You're probably wondering now 
You're probably wondering how 
Data flows between Model and View 
The Controller has to mediate 
Between each layer’s changing state 
To synchronize the data of the two 


It pulls and pushes every changed value 


Model View, mad props to the smalltalk trew! 
Model View Controller 


Model View, it’s pronounced Oh Oh not Ooo Ooo 


Model View Controller 


There's a little left to this story 
A few more miles upon this road 
Nobody seems to get much glory 
From writing the controller code 


Well the model’s mission eriti¢al 

And gorgeous is the view 

| might be lazy, but sometimes it’s just trazy 
How much code | write is just glue 

And it wouldn't be so tragi¢ 

But the code ain't doing magic 

It’s just moving values through 


And | don’t mean to be vicious 
But it gets repetitious 
Doing all the things tontrollers do 


And | wish | had a dime 


For every single time 


ECAR 
‘PQw ER 


Don't just read! After all this is a Head First book... grab your iPod, hit this URL: 
http://www.youtube.com/watch?v=Y YYOGPMLVDo 


Sit back and give it a listen. 


compound patterns 


| sent a TextField StringValue. 


Model View 
How we gonna deep six all that glue 
Model View Controller 


Controllers know the Model and View very intimately 


They often use hardéoding which can be foreboding for 
reusability 


But now you can connect each model key that you select 
to any view property 


And onte You start binding 
| think you'll be finding less code in Your source tree 


Yeah | know | was elated by the stuff they've automated 
and the things You get for free 


And | think it bears repeating 
all the code you won't be needing, 


when you hook it up iB. ae Using Cain 


Model View, even handles multiple selections too 
Model View Controller 


Model View, bet | ship my application before You 
Model View Controller 
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Cute song, but is that really 
supposed to teach me what Model- 
View-Controller is? I've tried 
learning MVC before and it made my 
brain hurt. 


No. Design Patterns are 
your key to the MVC. 


We were just trying to whet your appetite. 
Tell you what, after you finish reading this 
chapter, go back and listen to the song again 
— you'll have even more fun. 


It sounds like you’ve had a bad run in with 
MVC before? Most of us have. You’ve 
probably had other developers tell you it’s 
changed their lives and could possibly create 
world peace. It’s a powerful compound 
pattern, for sure, and while we can’t claim it 
will create world peace, it will save you hours 
of writing code once you know it. 


But first you have to learn it, right? Well, 
there’s going to be a big difference this time 
around because now you know patterns! 


That’s right, patterns are the key to MVC. 
Learning MVC from the top down is difficult; 
not many developers succeed. Here’s the 
secret to learning MVC: it’s just a few patterns 
put together. When you approach learning 
MVC by looking at the patterns, all of the 
sudden it starts to make sense. 


Let’s get started. This time around you’re 
going to nail MVC! 


Meet the Model-View-Controller 


compound patterns 


Imagine you’re using your favorite MP3 player, like iTunes. You can use its interface to add 
new songs, manage playlists and rename tracks. The player takes care of maintaining a little 
database of all your songs along with their associated names and data. It also takes care of 
playing the songs and, as it does, the user interface is constantly updated with the current song 


title, the running time, and so on. 


Well, underneath it all sits the Model-View-Controller... 


You You see the song 
display update and 
hear the new song 


playing 


Model tells the 
view the state has 
changed 


class Player 
} play()(} 


rip() {} 
burn () {} 


_/ Model 


The model contains all the state, 
data, and applica jon logie needed 
to maintain and play mP3s. 


uy US a 
oh ceria oY Ss 
scar 
ot ane 
TontrOule’ 
“Play new song” 
ee, 
Controller 
Controller asks 
Player model to 
begin playing 
song 
controller 
manipulates 


the model 


Now let’s zoom into the 
mvc up close 


A closer look... 


The MP3 Player description gives us a high level view of MVC, but it really doesn’t help you 
understand the nitty gritty of how the compound pattern works, how you’d build one yourself, or 
why it’s such a good thing. Let’s start by stepping through the relationships among the model, view 
and controller, and then we’ll take second look from the perspective of Design Patterns. 


CONTROLLER 


Takes user input and figures out 


what it means to the model. 
MODEL 


The model holds all 
VIEW the data, state and 


Here's the creamy lication logic. Th 
Gives you a presentation - it lives in application logic. e 
Dacdel controller it I model is oblivious to 


of the model. The view 


usually gets the state the middle. Le the view and controller, 
and data it needs to although it provides an 
display directly from interface to manipulate 
the model. y and retrieve its 
@ state and it can send 
notifications of state 
- i changes to observers. 
Change your 
The user did Controller state 
something 
Change your 
display class Player 


play(){} 


® eh 
q mn, 
I've changed! eel 


. ae Model 
~ ee need your state 


information 


Here's the model; 


This is the user +t handles all 
interface. application data 
and logit 
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You're the user — you interact with the view. 


compound patterns 


The view is your window to the model. When you do something to the view (like click 
the Play button) then the view tells the controller what you did. It's the controller's 


job to handle that. 


The controller asks the model to change its state. 


The controller takes your actions and interprets them. If you click on a button, it's 
the controller's job to figure out what that means and how the model should be 
manipulated based on that action. 


The controller may also ask the view to change. 


When the controller receives an action from the view, it may need to tell the view 
to change as a result. For example, the controller could enable or disable certain 
buttons or menu items in the interface. 


The model notifies the view when its state has changed. 


When something changes in the model, based either on some action you took (like 
clicking a button) or some other internal change (like the next song in the playlist 
has started), the model notifies the view that its state has changed. 


The view asks the model for state. 


The view gets the state it displays directly from the model. For instance, when the 
model notifies the view that a new song has started playing, the view requests the 
song name from the model and displays it. The view might also ask the model for 
state as the result of the controller requesting some change in the view. 


Q: Does the controller ever become 
an observer of the model? 


A: Sure. In some designs the controller 
registers with the model and is notified 

of changes. This can be the case when 
something in the model directly affects the 
user interface controls. For instance, certain 
states in the model may dictate that some 
interface items be enabled or disabled. If 
So, it is really controller’s job to ask the view 
to update its display accordingly. 
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Dumb Questions 


Q: All the controller does is take user 
input from the view and send it to the 
model, correct? Why have it at all if that 
is all it does? Why not just have the code 
in the view itself? In most cases isn’t the 
controller just calling a method on the 
model? 


The controller does more than 
just “send it to the model’, the controller is 
responsible for interpreting the input and 
manipulating the model based on that input. 
But your real question is probably “why can’t 
| just do that in the view code?” 


You could; however, you don’t want to 

for two reasons: First, you'll complicate 
your view code because it now has two 
responsibilities: managing the user interface 
and dealing with logic of how to control the 
model. Second, you're tightly coupling your 
view to the model. If you want to reuse 

the view with another model, forget it. The 
controller separates the logic of control from 
the view and decouples the view from the 
model. By keeping the view and controller 
loosely coupled, you are building a more 
flexible and extensible design, one that can 
more easily accommodate change down the 
road. 
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Looking at MVC through 
patterns-colored glasses 


We've already told you the best path to learning the MVC is to see it for what it 
is: a set of patterns working together in the same design. 


Let’s start with the model. As you might have guessed the model uses 
Observer to keep the views and controllers updated on the latest state changes. 
The view and the controller, on the other hand, implement the Strategy Pattern. The controller 
is the behavior of the view, and it can be easily exchanged with another controller if you 

want different behavior. The view itself also uses a pattern internally to manage the windows, 
buttons and other components of the display: the Composite Pattern. 


Let’s take a closer look: 


Strategy 


The view and controller implement the classic Strategy Pattern: the 
view is an object that is configured with a strategy. The controller 
provides the strategy. The view is concerned only with the visual 
aspects of the application, and delegates to the controller for any 
decisions about the interface behavior. Using the Strategy Pattern also 
keeps the view decoupled from the model because it is the controller 
that is responsible for interacting with the model to carry out user 
requests. The view knows nothing about how this gets done. 


——— 


y 


Controller 


gownos 
af 


burn () {} 


Model 


View 


The model implements the Observer Pattern 


The display consists of a nested set of win- 
dows, panels, buttons, text labels and so on. 
Each display component is a composite (like 

a window) or a leaf (like a button). When the 
controller tells the view to update, it only has 
to tell the top view component, and Composite 
takes care of the rest. 
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to keep interested objects updated when state 
changes occur. Using the Observer Pattern 
keeps the model completely independent of 
the views and controllers. It allows us to use 
different views with the same model, or even 
use multiple views at once. 


compound patterns 


Observer 


Observers 


i All these observers will be 


notified whenever state 
Observable 


changes in the model. 
My state has 
: changed! 
2 Foo 
void bar( 
i} 
Model 
cx Controller 
| Any object a a 
I'd like to register praia ts ae 
es VV 
Be Cinder Nes View Se with the The model has no dependencies on 
“A gs an observer: viewers or Controllers! 
mo 


Strategy 


The controller is the 


The user did ———— 
ae 3 : 


thi sbrates Lor the view 
a something : Us i abject that 
Th : Knows how to handle 
e@ vi ‘ions: 
delegates to Controller the se" tHe" 
the controller 
to handle the 


EN We Can SwaP in 
user attions, 


another behavior i. 
the view by Changing 
the controller. 


View 


The view only worries about presentation, the controller worries Controller 
about translating user input to actions on the model. 


Composite paint 


The view is a composite of 


(000 Window a) Gul Components (labels, 
——————— 
| SetBPM; buttons, text entry) 


ete). The top level 
SS Component contains other 


Components, which contain 
other Components and so 
= on until you get to the 


leaf nodes: 
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mve and the dj view 


Using MVC to control the beat... 


It’s your time to be the DJ. When you’re a DJ it’s all about the beat. You might start 
your mix with a slowed, downtempo groove at 95 beats per minute (BPM) and then 
bring the crowd up to a frenzied 140 BPM of trance techno. You'll finish off your set 
with a mellow 80 BPM ambient mix. 


How are you going to do that? You have to control the beat and you’re going to build 
the tool to get you there. 


Meet the Java DJ View 


Let’s start with the view of the tool. The view allows you to create a 
driving drum beat and tune its beats per minute... 


The view has wo parts, wi 
the part Lor viewing, the 
state of the model and 
the part Lor controlling, 


things: —— 


A pulsing bar shows the beat in veal time. 


A display shows the current BPMs and is 
automatically set whenever the BPM changes. 


@ 0 @ Control 
Dj Control 


Enter BPM: 


You tan enter a specifi BPM and elick 
T—+§$——_ the Set button to set a specific beats 

per minute, or You Can use the inérease 

and deerease buttons for fine tuning. 


Deereases the Increases the 
BPM by one BPM by one 
beat per minute: beat per minute. 
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Here’s a few more ways to ¢ontrol the DJ View... 


8 0 @ Control 


Dj Control — 


You can start the beat 


Yo kicking, by choosing, the 
Ctart menu stem in the 
“DJ Control” menu 


Notice Stop is 
disabled until you 
start the beat. 


The controller is in the middle... 


The controller sits between the view and 

model. It takes your input, like selecting “Start” 
from the DJ Control menu, and turns it into an 
action on the model to start the beat generation. 


The controller takes input 
from the user and figures out 
how to translate that into 
requests on the model. 


compound patterns 


You use the Stop 
button to shut 
down the beat 
generation. 


disabled after the / 


Notice Start is 
beat has started. 


8 © © Control 
Dj Control 


All user actions are 
sent to the controller. 


— 


—— 


Controller 


Let’s not forget about the model underneath it all... 


You can’t see the model, but you can hear it. The 
model sits underneath everything else, managing the 
beat and driving the speakers with MIDI. 


The BeatModel is the heart of the 
application. |t implements the logie 
to start and stop the beat, set 
the beats per minute (BPM), and 
generate the sound. 


The model also allows us to 
obtain its current state through 
the getBPM() method. 
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the dj model, view and controller 


Putting the pieces together 


The beat is set at 119 BPM and you 
would like to increase it to 120. | 


0 O @ Control 
Dj Control 


Enter BPM: Click on the 
increase beat 
button... 

es which results in the 
controller being invoked. 

y The controller asks 
the model to update 
its BPM by one. 

Controller 
You see the beatbar 
pulse every 1/2 second. ‘s 
atMo 
View y Because the BPM is 12.0, the view gets Qe Ae, 
eae a a beat notification every 1/2. second. 
2S 8 Mew === setBPM() off()_ 
Current BPM: 120 KY ge 0 
The view is updated View is notified that the BPM 
to 120 BPM. changed. [t ealls get BPMO on 
the model state. 


536 Chapter 12 


Building the pieces 


compound patterns 


Okay, you know the model is responsible for maintaining all the data, state and any 
application logic. So what’s the BeatModel got mm it? Its main job is managing the beat, 
so it has state that maintains the current beats per minute and lots of code that generates 
MIDI events to create the beat that we hear. It also exposes an interface that lets the 
controller manipulate the beat and lets the view and controller obtain the model’s state. 
Also, don’t forget that the model uses the Observer Pattern, so we also need some methods 
to let objects register as observers and send out notifications. 


Let’s check out the BeatModellnterface before looking at the 


implementation: 


These are the methods 
the controller will use to 
direct the model based on 


user interaction. 


These methods allow 
the view and the 
controller to get 

state and to become 


observers: 


public interface BeatModellInterface { 


void initialize(); << Be 
aoe These methods turn the beat 
ep ome Se generator on and off. 
void off(); This method sets the beats per 
a minute. After it is called, the beat 


void setBPM(int bpm) ; frequency changes immediately. 


int getBPM(); = The get BPMO method returns 
the current BPMs, or O if 
void registerObserver (BeatObserver 0); the generator is off. 


void removeObserver (BeatObserver 0); 


void registerObserver (BPMObserver 0); 
eo 


void removeObserver (BPMObserver o); 


My 


This should look 
familiar, these 
methods allow 
objects to register 
as observers for 


state changes. 


We've split this into two kinds of 
observers: observers that want to be 
notified on every beat, and observers 
that just want to be notified with 
the beats per minute change. 
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the beat mode! 


Now let’s have a look at the concrete BeatModel class: Tid wstdeg fe, 
We implement the BeatModellnterface. ) - the MIDI code. 


public class BeatModel implements BeatModelInterface, MetaEventListener { 


Sequenter sequencer; << The sequencer is the object + 
: _ : : ree hat knows how to 
ArrayList beatObservers new ArrayList (); generate veal beats (that you ¢an heat 


ArrayList bpmObservers = new ArrayList(); \ 

int bpm = 90; . ‘ 
Lists hold the two kinds o 

// other instance variables here WEN These ArrayLi 


observers (Beat and BPM observers). 


public void initialize() { This method does 
setUpMidi () ; a 
buildTrackAndStart (); 


The bpm instance variable holds the Frequency 
setup on the sequencer of beats — by default, 70 BPM. 


} and sets up the beat 


tracks for us. 
public void on() { 
sequencer.start(); <The on() method starts the sequencer and 
setBPM(90) ; sets the BPMs to the default: 90 BPM. 
} 
public void off() { —o——_— And of f() shuts it down by setting BPMs to 
setBPM (0); O and stopping the sequencer. 


sequencer.stop(); 


} | The setBPMOQ method is the way the controller 


; manipulates the beat. It does three things: 
public void setBPM(int bpm) { 


this.bpm = bpm; —— (I) Sets the bpm instance variable 
sequencer.setTempoInBPM (getBPM() ); ; 
notifyBPMObservers (); x (2) Asks the sequencer to change its BPMs. 
} ee (3) Notifies all BPM Observers that the BPM has 
changed. 


public int getBPM() { 
return bpm; 


The 9¢tBPMO method just returns the bpm instante variable, which 
indicates the current beats per minute: 
hae mM— ith is not in the BeatModellnterface, is 
he beatEvent() method, which is not in 
sie hiaioeaad bie the MID] eode whenever a new beat starts. This method 
| notifies all BeatObservers that a new beat has just otturred. 


} 


// Code to register and notify observers 


// Lots of MIDI code to handle the beat <—~ 
} 


Ready-bake Code 


This model uses Java’s MIDI support to generate beats. You can check out the 


complete implementation of all the DJ classes in the Java source files available 
on the wickedlysmart.com site, or look at the code at the end of the chapter. 
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The View 


Now the fun starts; we get to hook up a view and visualize the BeatModel! 


The first thing to notice about the view 1s that we’ve implemented it so that it is displayed in two separate 
windows. One window contains the current BPM and the pulse; the other contains the interface 
controls. Why? We wanted to emphasize the difference between the interface that contains the view of 
the model and the rest of the interface that contains the set of user controls. Let’s take a closer look at 


the two parts of the view: 
Weve separated 
Zz. the view of the 


model from the 
6 © © View view with the 


vols. 
Current BPM: 120 a @ © O Control 
tae " DJ Control 
displays two 
ie of the Enter BPM: 
a (se) 
the current beats and a pulsing “beat =| 
per minute, from bar” pulses in synth a 
the BPMObserver with the beat, driven ei 
salibications= by the BeatObserver his is the Part of the 
notifications. You use to Change the b, Hog 
View Passes eventp eee This 


ios RAIN 
Our BeatModel makes no assumptions about the view. The model is implemented using the 
Observer Pattern, so it just notifies any view registered as an observer when its state changes. The 


view uses the model’s API to get access to the state. We’ve implemented one type of view, can you 
think of other views that could make use of the notifications and state in the BeatModel? 


A lightshow that is based on the real-time beat. 


A textual view that displays a musi¢ genre based on the BPM (ambient, downbeat, techno, ett.). 
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the dj view 


Implementing the View 


The two parts of the view — the view of the model, and 
the view with the user interface controls — are displayed 
im two windows, but live together in one Java class. We'll 
first show you just the code that creates the view of the 
model, which displays the current BPM and the beat bar. 
Then we'll come back on the next page and show you just 
the code that creates the user interface controls, which 
displays the BPM text entry field, and the buttons. 


The code on these two 
Wateh it! Pages is just an outline! 


What we've done here is split ONE 
class into TWO, showing you one part 
of the view on this page, and the other 
part on the next page. Alll this code is 
really in ONE class - DJView.java. It's 
all listed at the back of the chapter. 


DuView is an observer for both real-time beats and BPM changes. 


L 


public class DJView implements ActionListener, BeatObserver, BPMObserver { 

BeatModelInterface model; . 

Ae CL SAAN eer <S—~ The view holds a reference to both the model and 

dinate Sdewseanes the controller. The controller is only used by the 

Shane. wieweane 4 mM control interface, which we'll go over in a set... 
ere, we create a fey, 

BeatBar beatBar; com ks £ 

JLabel bpmOutputLabel; Ponents tor the display. 


public DJView(ControllerInterface controller, BeatModelInterface model) { 
this.controller = controller; 


‘ —___ The constructor gets a reference to 
enn ‘ a ( (BeatOb ee the controller and the model, and 
mo .cregisterObserver a server is); aan the 
model.registerObserver ((BPMObserver) this) ; we store references to 
} instance variables. 
public void createView() { We also register as a BeatObserver and a 
// Create all Swing components here BPMObserver of the model. 


} 


a The updateBPM() method is called when a state change 
ee Te, oteurs in the model. When that happens we update the 


int bpm = model.getBPM(); i display with the current BPM. We ean get this value b 

Ae Ape Ss). 4 requesting it directly from the model. : 
bpmOutputLabel.setText (“offline”) ; 

} else f 
bpmOutputLabel.setText (“Current BPM: “ + model.getBPM()); 


} 
} 
Likewise, the updateBeat() method is called when 
pubiin wedd Wisdarebese ty: 3 the model starts a new beat. When that happens, 
beatBar.setValue (100); we need to pulse our “beat bar.” We do this b 
setting it to its maximum value (IOO) and letting 
it handle the animation of the pulse. 


} 


540 Chapter 12 


Implementing the View, continued... 


compound patterns 


Now, we'll look at the code for the user interface controls part of the view. This view lets you control the 
model by telling the controller what to do, which in turn, tells the model what to do. Remember, this code 


is in the same class file as the other view code. 


public class DJView implements ActionListener, B 


BPMObserver { 


BeatModelInterface model; 
ControllerInterface controller; 
JLabel bpmLabel; 
JTextField bpmTextField; 
JButton setBPMButton; 
JButton increaseBPMButton; 
JButton decreaseBPMButton; 
JMenuBar menuBar; 

JMenu menu; 

JMenulItem startMenultem; 
JMenuItem stopMenulItem; 


3 


public void createControls() { 


// Create all Swing components here 
or 


talled on the controller. 


public void enableStopMenulItem() { 
stopMenultem.setEnabled (true) ; 


{ 
\e 


public void disableStopMenulItem() 
stopMenultem.setEnabled(fals 


public void enableStartMenulItem() 
startMenuItem.setEnabled (tru 


{ 
\e 


{ 
\e 


public void disableStartMenuItem() 
startMenultem.setEnabled(fals 


Dj Control 


This method creates all 
interface. It also 


atObserver, 


@ 0 0 Control 


the controls and places them in the 
takes eave of the menu. When the stop 
items are chosen, the Corresponding methods are 


start 


All these methods allow the start and 

stop items in the menu to be enabled and 
disabled. We'll see that the controller uses 
these to change the interface. 


This method is called when a button is clicked. 


If the Set button is 
clicked then it is passed 
on to the controller along, 
with the new bpm. 


Likewise, if the intrease 
or decrease buttons are 


EK tlieked, this information is 


{ 


{ 


public void actionPerformed(ActionEvent event) { 

if (event.getSource() == setBPMButton) { 
int bpm = Integer.parselInt (bpmTextField.getText ()); 
controller.setBPM (bpm) ; 

} else if (event.getSource() == increaseBPMButton) 
controller.increaseBPM () ; 

} else if (event.getSource() == decreaseBPMButton) 
controller.decreaseBPM () ; 


passed on to the controller. 
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the dj controller 


Now for the Controller 


It’s time to write the missing piece: the controller. Remember the controller is 
the strategy that we plug into the view to give it some smarts. 


Because we are implementing the Strategy Pattern, we need to start with an 
interface for any Strategy that might be plugged into the DJ View. We’re going 
to call it ControllerInterface. 


Here are all the 


Zs methods the view can 

tall on the ¢ 

public interface ControllerInterface { eee 
void start(); 


void stop(); ae These should look familiar after seeing, the model’s 

void increaseBPM(); KO interface. You tan stop and start the beat 

void decreaseBPM () ; —~ generation and Change the BPM. This interface is 

WOH) SecPEe ine Epis a “richer” than the BeatModel interface because you 
can adjust the BPMs with intrease and decrease. 


RS Design Puzzle 


You've seen that the view and controller together make use of the Strategy Pattern. Can you draw a 
class diagram of the two that represents this pattern? 
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And here's the implementation of the controller: 


The controller implements 
the ControllerInterface. 


public class BeatController implements ControllerInterface { 


BeatModelInterfac 
DJView view; 


model; 


public BeatController (BeatModelInterfac 


The controller is the creamy stuff in 


td the middle of the MVC oreo cookie, 
so it is the object that gets to hold 


this.model = model; 
view = new DJView(this, 
view.createView(); 
view.createControls(); 
view.disableStopMenultem () ; 
view.enableStartMenultem () ; 
model.initialize(); 


} 


public void start() { 
model.on(); 
view.disableStartMenulItem() ; 

nableStopMenulItem(); 


view. 


} 


public void stop() { 
model.off(); 
view.disableStopMenultem () ; 


view.enableStartMenulItem (); 


} 


public void increaseBPM() { 
int bpm = model.getBPM(); 
model.setBPM(bpm + 1); 

} 


public void decreaseBPM() { 


int bpm = model.getBPM(); 
model.setBPM(bpm - 1); KQ. 


} 


public void setBPM(int bpm) { 
model.setBPM (bpm) ; 
} 


model); 


a 


a 


model) { on to the view and the model and 
glues it all together. 


aaa The controller is passed the 


model in the constructor and 
then ereates the view. 


When you Choose Chart from the user 
interface menu, the controller turns the 
model on and then alters the user interface 
so that the start menu item is disabled and 
the stop menu item is enabled. 


Likewise, when You choose Stop from the 
menu, the Controller turns the model of f 
and alters the user interface so that 
the stop menu item is disabled and the 
start menu item is enabled. 


If the increase button is clicked, the 
controller gets the current BPM 
from the model, adds one, and then 
sets a new BPM. 


NOTE: the controller is 
making the intelligent 
decisions for the view. 
The view just knows how 
to turn menu items on 
and of f; it doesn’t know 
the situations in which it 
should disable them. 


Same thing here, only we subtract 
one from the current BPM. 


Finally, if the user interface is used to 
set an arbitrary BPM, the controller 
instructs the model to set its BPM. 
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putting it all together 


Putting it all together... 


We've got everything we need: a model, a view, and a controller. 
Now it’s time to put them all together into a MVC! We’re going to 
see and hear how well they work together. 


All we need 1s a little code to get things started; it won’t take much: 


public class DJTestDrive { a. 


public static void main (String[] args) { First create a model... 
BeatModelInterface model = new BeatModel (); 
ControllerInterface controller = new BeatController (model); 


} then create a controller and 
pass it the model. Remember, the 
controller creates the view, so we 


don’t have to do that. 


And now for a test run... 
Run this... 
and you'll see this. 
— 
Things to do @ 0 0 View @ © @ Control 


e Start the beat generation with the Start menu item; 
notice the controller disables the item afterwards. 


Dj Control 
Enter BPM: 


Current BPM: 120 


e Use the text entry along with the increase and decrease Ee 
buttons to change the BPM. Notice how the view 
display reflects the changes despite the fact that it has 


no logical link to the controls. 


(3) Notice how the beat bar always keeps up with the beat ES 
since it’s an observer of the model. 


(4) Put on your favorite song and see if you can beat match 
the beat by using the increase and decrease controls. 


(5) Stop the generator. Notice how the controller disables 
the Stop menu item and enables the Start menu item. 
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Exploring Strategy 


Let’s take the Strategy Pattern just a little further to get a better 
feel for how it is used m MVC. We're going to see another 
friendly pattern pop up too — a pattern you'll often see hanging 
around the MVC trio: the Adapter Pattern. 


Think for a second about what the DJ View does: it displays 

a beat rate anda pulse. Does that sound like something else? 
How about a heartbeat? It just so happens we happen to have a 
heart monitor class; here’s the class diagram: 


Weve got a method Lor getting 

HeartModel : 
eurvent heart va 

getHeartRate() thee 

registerBeatObserver() 


registerBPMObserver() 3 —_—._ And luckily, its developers knew about 
// other heart methods the Beat and BPM Observer interfaces! 


oe RAW 
It certainly would be nice to reuse our current view with the HeartModel, but we need a controller that 
works with this model. Also, the interface of the HeatModel doesn’t match what the view expects 


because it has a getHeartRate() method rather than a getBPM(). How would you design a set of 
classes to allow the view to be reused with the new model? 


mve and adapter 


Adapting the Model 


For starters, we’re going to need to adapt the HeartModel to a BeatModel. If we don’t, the view 
won't be able to work with the model, because the view only knows how to getBPM(), and the 
equivalent heart model method is getHeartRate(). How are we going to do this? We’re gomg to 
use the Adapter Pattern, of course! It turns out that this is a common technique when working 
with the MVC: use an adapter to adapt a model to work with existing controllers and views. 


Here’s the code to adapt a HeartModel to a BeatModel: 
We need to implement the 


< target interface, in this Case, 
BeatModellnterface. 
public class HeartAdapter implements BeatModelInterfac 
HeartModelInterface heart; 


public HeartAdapter (HeartModelInterface heart) > ence stove a veferente 
this.heart = heart; bathe Padi 


} 


public void initialize() {} KN ee eee eee Te 
qe toa heart, but it sou stan So 


a we'll just leave them as “no ops.” 
public void off() {} 


When get BPM) is called, we'll just 
mee cee = branlate it to a gettteartRatel) call 
return heart.getHeartRate(); ee al 


ee We don’t want to do this on a heart! 


Again, let's leave it as a “no op”. 


public void on() {} 


} 


public void setBPM(int bpm) {} 


public void registerObserver (BeatObserver o) { 
heart.registerObserver (0); 


} 
Here are our observer methods. 
public void removeObserver(BeatObserver o) { We just delegate is te the 


heart.removeObserver (0) ; wrapped heart model. 


} 


public void registerObserver (BPMObserver o) { 
heart.registerObserver (0); 


} 


public void removeObserver(BPMObserver o) { 
heart.removeObserver (0); 


} 
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Now we're ready for a HeartController 


With our HeartAdapter in hand we should be ready to create a controller and get the 


view running with the HeartModel. ‘Talk about reuse! 
The HeartController implements 
the Controllerlnterface, just 
like the BeatController did. 
public class HeartController implements ControllerInterface { 


HeartModeliInterface model; 
DJView view; 


public HeartController (HeartModelInterface model) { pac uaa 
this.model = model; ge 
view = new DJView(this, new HeartAdapter (model) ); everything glued together. 
view.createView(); 
view.createControls(); 
view.disableStopMenuItem () There is one Change: we are passed a 


view.disableStartMenuItem ( HeartModel, not a BeatModel 

} poe 
| | and we need to wrap that 

public void start ( model with an adapter before 

ee er we hand it to the view. 


Finally, the HeartController disables the 


public void increaseBPM ( a items as they aren't needed. 


pia ee ener i not a lot to do here; 
after all, we can't really control 
hearts like we can beat machines. 


public void setBPM(int bpm) 


And that’s it! Now it’s time for some test code... 


public class HeartTestDrive { 


public static void main (String[] args) { 
HeartModel heartModel = new HeartModel (); 
ControlleriInterface model = new HeartController (heartModel) ; 


All we need to do is ereate 
the controller and pass it a 
heart monitor. 
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test the heart model 


And now for a test run... 


File Edit Window Help CheckMyPulse 


java HeartTestDrive 


..and you'll see this. Wy 


Things to do 


2) 
3) 


°o 
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Notice that the display works great with a heart! 

The beat bar looks just like a pulse. Because the 
HeartModel also supports BPM and Beat Observers we 
can get beat updates just like with the DJ beats. 


As the heartbeat has natural variation, notice the 
display is updated with the new beats per minute. 


Each time we get a BPM update the adapter is doing 
its job of translating getBPM() calls to getHeartRate() 
calls. 


The Start and Stop menu items are not enabled 
because the controller disabled them. 


The other buttons still work but have no effect 
because the controller implements no ops for them. 
The view could be changed to support the disabling of 
these items. 
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Run this... 


A OO Control 


Dj Control 
Enter BPM: 


Set 


<< >> 


@ © © View 
| 


| Current BPM: 68 
———— 


Nice healthy 
heart rate. 
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MVC and the Web 


Tt wasn’t long after the Web was spun that developers started adapting the MVC to fit the 
browser/server model. The prevailing adaptation is known simply as “Model 2” and uses a 
combination of servlet and JSP technology to achieve the same separation of model, view and 
controller that we see in conventional GUIs. 


Let’s check out how Model 2 works: 


\<-_ 

— ~ a model/DB/ 

jz======53 fs) © ai business logic 
Client JSp/view 


@ You make an HTTP request, which is received by a servlet. 


Using your web browser you make an HTTP request. This typically involves 
sending along some form data, like your username and password. A servlet 
receives this form data and parses it. 


@ The servlet acts as the controller. 


The servlet plays the role of the controller and processes your request, 
most likely making requests on the model (usually a database). The result 
of processing the request is usually bundled up in the form of a JavaBean. 


©) The controller forwards control to the view. 
The View is represented bya JSP. The JSP's only job is to generate 
the page representing the view of model (@which it obtains via the 
JavaBean) along with any controls needed for further actions. 

© The view returns a page to the browser via HTTP. 


A page is returned to the browser, where it is displayed as the view. The 
user submits further requests, which are processed in the same fashion. 
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Model 2 is more than just 
a clean design. 


The benefits of the separation of the view, 
model and controller are pretty clear to 
you now. But you need to know the “rest 
of the story” with Model 2 — that it saved 
many web shops from sinking into chaos. 


How? Well, Model 2 not only provides 

a separation of components in terms of 
design, it also provides a separation in 
production responsibilities. Let’s face it, in the 
old days, anyone with access to your JSPs 
could get in and write any Java code they 
wanted, right? And that included a lot 
of people who didn’t know a jar file from 
a jar of peanut butter. The reality is that 
most web producers know about content and 
HTML, not software. 


Luckily Model 2 came to the rescue. 
With Model 2 we can leave the developer 
jobs to the guys & girls who know their 
Servlets and let the web producers loose 
on simple Model 2 style JSPs where all 
the producers have access to is HTML 
and simple JavaBeans. 


You don't even want to 
know what life was like before 
Model 2 came on the scene. It was 


ugly. 


former DOT COM’er 
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Model 2: DJ’ing from a cell phone 


You didn’t think we’d try to skip out without moving that 
great BeatModel over to the Web did you? Just think, you can 
control your entire DJ session through a web page on your 
cellular phone. So now you can get out of that DJ booth and 
get down in the crowd. What are you waiting for? Let’s write 
that code! 


The plan 


@) Fix up the model. 
Well, actually, we don't have to fix the model, it's fine just 
like it is! 


Q) Create a servlet controller 
We need a simple servlet that can receive our HTTP 
requests and perform a few operations on the model. All it 
needs to do is stop, start and change the beats per minute. 


® Create a HTML view. 
We'll create a simple view witha JSP. It's going to receive 
a JavaBean from the controller that will tell it everything 
it needs to display. The JSP will then generate an HTML 
interface. 


a Geek Bits 


Showing you how to set up your servlet environment is a little bit off 
topic for a book on Design Patterns, at least if you don’t want the book 
to weigh more than you do! 


Setting up your Servlet environment 


Fire up your web browser and head straight to 
http:/jakarta.apache.org/tomcat/ for the Apache Jakarta Project’s 
Tomcat Servlet Container. You'll find everything you need there to get 
you up and running. 


You'll also want to check out Head First Servlets & JSP by Bryan 
Basham, Kathy Sierra and Bert Bates. 


model 2 controller servlet 


Step one: the model 


Remember that in MVC, the model doesn’t know anything about the views or 
controllers. In other words it is totally decoupled. All it knows 1s that it may have 
observers it needs to notify. That’s the beauty of the Observer Pattern. It also 
provides an interface the views and controllers can use to get and set its state. 


Now all we need to do 1s adapt it to work in the web environment, but, given that 
it doesn’t depend on any outside classes, there is really no work to be done. We 
can use our BeatModel off the shelf without changes. So, let’s be productive and 
move on to step two! 


Step two: the controller servlet 


Remember, the servlet is going to act as our controller; it will recetve Web browser 
input ina HTTP request and translate it into actions that can be applied to the 
model. 


Then, given the way the Web works, we need to return a view to the browser. ‘To 
do this we'll pass control to the view, which takes the form of a JSP. We'll get to 


that in step three. 
Here’s the outline of the servlet; on the next page, we'll look at the full 
implementation. 
We extend the HttpServlet class 
so that we can do servlet kinds of 
things, like receive HTTP requests. 
public class DJView extends HttpServlet { Here’s the init method} 
——— this is called when the 
public void init() throws ServletException { seedlek is Lek eveated: 


BeatModel beatModel = new BeatModel (); 
beatModel.initialize(); 


getServletContext ().setAttribute (“beatModel”, beatModel) ; We first create a 
BeatModel object. 


// doPost method here 7 and place a reference to 


it in the servlet’s context 


public void doGet (HttpServletRequest request, so that it’s easil Ashbcceed 
HttpServletResponse response) Y . 
throws IOException, ServletException 
{ 
// implementation here ; 
Here’s the doGet() method. This is where the real work 
happens. We've got its implementation on the next page. 
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Here’s the implementation of the doGet() method from the page before: 


First we grab the model from 


t 
public void doGet (HttpServletRequest request, the servlet context. me ee) 
HttpServletResponse response) manipulate the model without a 
throws IOException, ServletException reference to it. 


BeatModel beatModel = 
(BeatModel) getServletContext () .getAttribute (“beatModel”) ; 


String bpm = request.getParameter (“bpm”) ; 
if (bpm == null) { Next we grab all the HTTP 
bpm = beatModel.getBPM() + “”; Commands/ parameters... 


a 


String set = request.getParameter (“set”); , If me get a set Command, then 

fe fest t= naa) we get the value of the set, 
int bpmNumber = 90; and tell the model. 
bpmNumber = Integer.parselInt (bpm) ; 


beatModel.setBPM (bpmNumber) ; 
} 
String decrease = request.getParameter (“decrease”) ; 
if (decrease != null) { : detrease, we get the 

beatModel.setBPM (beatModel.getBPM() - 1); To inevease 0 odel, and 
} : VA eurvent BPMs from the mode 

by one. 

String increase = request.getParameter (“increase”); adjyst up or down DY 
if (increase != null) { 

beatModel.setBPM (beatModel.getBPM() + 1); 


} 


String on = request.getParameter (“on”) ; —_ If we get an on or of f Command 
if (on != null) { " oo 
pee es a tell the model to start or stop. 

} 

String off = request.getParameter (“off”); Finally, our job as a Controll 

if (off != null) { a 
eee ee Os is done. All we need to do is 

' ask the view to take over and 


treate an HTML view. 
request.setAttribute (“beatModel”, beatModel) ; 


RequestDispatcher dispatcher = Following the Model 2. definition, 
request.getRequestDispatcher (“/jsp/DJView.jsp”) ; pr / we pass the JSP a bean with the 
dispatcher.forward(request, response) ; model state in it. In this case, we 
} pass it the a¢tual model, since it 
happens to be a bean. 
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Now we need a view... 


All we need is a view and we’ve got our browser-based beat generator ready to go! 
In Model 2, the view is just a JSP. All the JSP knows about is the bean it receives 
from the controller. In our case, that bean is just the model and the JSP is only 
going to use its BPM property to extract the current beats per minute. With that 


data in hand, it creates the view and also the user interface controls. ) . 
Here's our bean, which 


f the servlet passed us. 


<jsp:useBean id="beatModel” scope="request” class="headfirst.combined.djview.BeatModel” /> 


2henis Beginning of the HTML. i 

pone ere we use the model bean to 
<title>DJ View</title> _. extract the BPM property. 
</head> 

<body> a ) 

Now we 
<h1l>DJ View</h1> generate the 
Beats per minutes = <jsp:getProperty name="beatModel” property=”"”BPM” /> view, which 
<br /> prints out 
tae the current 
<br /> 

beats per 
<form method="post” action="/djview/servlet/DJView”> minute. 
BPM: <input type=text name="bpm” 

value="<jsp:getProperty name="beatModel” 

property="BPM” />”> 
é&nbsp; 
<input type="submit” name="set” value="set”><br /> 
<input type="submit” name="decrease” value="<<"> And here’s the control part 
<input type="submit” name="increase” value=">>"><br /> of the view. We have a text 
<input type="submit” name="on” value="on”> entry Lor entering a BPM 
<input type="submit” name="off” value="off”><br /> along with intrease/detrease 
eee and on/off buttons. 
</body> 


</html> 


find here’s the end 
of the HTML. 


NOTICE that just like MVC, in Model 2 
the view doesnt alter the model (that’s the 
tontroller’s job); all it does is use its statel 
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Putting Model 2 to the test... 


It’s time to start your web browser, hit the DJ View Servlet and give 
the system a spin... 


aT Qy Google 


This is the view DJ View (1) User clicks the 
of the model: 


on button. 
(2) Request is sent to 
Here's the set of BPM:|0=—t—~<“‘it‘:s™sCSCSCS Cet) tontroller via HTTP. 
trols; when aes 
they get sent via (3) Beat ; 
d set a 
TP to the -_ on an 
aa tontraller SE default 90 BPM. 
Lor processing: = —<———— 
DJ View (4) View is returned 
via HTTP and 
Best permis =90 
(5) User enters new 
Bom: | i 3) BPM in text field. 
(b) User clicks 
Set button. 
(D) HTTP request 
is made. 
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(8) Controller 
changes model to 
150 BPMs 


(9) View returns rs 
HTML reflecting 


— D) View a = 
G @http:/ /localhost:8080/djvi@ ~(Q> Google 


Yahoo! Local News: 


ddress Book*y Apple 
DI View 


DJ View 


Beats per minutes = 150 


Amazon 


the current model. 


Things to do 


1) First, hit the web page; you’ll see the beats per minute at 0. Go ahead and 
click the “on” button. 


Now you should see the beats per minute at the default setting: 90 BPM. You 
should also hear a beat on the machine the server is running on. 


Enter a specific beat, say, 120, and click the “set” button. The page should 
refresh with a beats per minute of 120 (and you should hear the beat 
increase). 


Now play with the increase/decrease buttons to adjust the beat up and down. 


oo oO © 


Think about how each step of the system works. The HTML interface makes 
a request to the serviet (the controller); the serviet parses the user input and 
then makes requests to the model. The serviet then passes control to the 
JSP (the view), which creates the HTML view that is returned and displayed. 
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After implementing the DJ Control for the Web using Model 2, you might be wondering where the patterns 
went. We have a view created in HTML from a JSP but the view is no longer a listener of the model. We have 
a controller that’s a servlet that receives HTTP requests, but are we still using the Strategy Pattern? And what 
about Composite? We have a view that is made from HTML and displayed in a web browser. Is that still the 


Composite Pattern? 


Model 2 is an adaptation of MVC to the Web 


Even though Model 2 doesn’t look exactly like “textbook” MVC, all the parts are still there; they’ve just been 
adapted to reflect the idiosyncrasies of the web browser model. Let’s take another look... 


Observer 


The view is no longer an observer 
of the model in the classic 
sense; that is, it doesn't register 
with the model to receive state 
change notifications. 


However, the view does receive 
the equivalent of notifications 
indirectly from the controller 
when the model has been 
changed. The controller even 
passes the view a bean that 
allows the view to retrieve the 
model's state. 


If you think about the browser 
model, the view only needs an 
update of state information 
when an HTTP response is 
returned to the browser; 
notifications at any other time 
would be pointless. Only when 
a page is being created and 
returned does it make sense to 
create the view and incorporate 
the model's state. 


Here's a new page 
to display 


JSP/HTML 
View 


The view now receives 
potirications from the 
tontroller when 2 Pa9e 
is needed yather than 
on every 


the model: 


state change 
setBPM()  off() 


Web 
browser 


User has done 


something 


=> 


bean 


Update your display, 
4<—— here's the new model 


state an J 


Controller 
Okay, I changed 
my state 
| Change your 
geatMog. / state 


on) 


getBP NY) 
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Strategy 


In Model 2, the Strategy 
object is still the controller 
servlet; however, it's not 
directly composed with the 
view in the classic manner. 
That said, it is an object that 
implements behavior for the 
view, and we can swap it out 
for another controller if we 
want different behavior. 


Here's a new page 
to display 


JSP/HTML 
View 
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Web 
browser 


> 


bean 


Update your display, 
4<—— here's the new model 


state Oe J 


Okay, I changed 
my state 


| 


gest Mog. / 


on() 


setBPM()  off() 


9 etBP INIA) 


Composite 


Like our Swing GUI, the 
view is ultimately made up 
of a nested set of graphical 
components. In this case, 
they are rendered bya 
web browser from an 
HTML description, however 
underneath there is an 


object system that most 
> \ likely forms a composite. 


User has done 


something 


The tontroller still 
provides the view 
behavior, even if it 
isn ¢ composed with 
the view using object 


composition. 


Controller 


Change your 
state 


Q: It seems like you are really hand 
waving the fact that the Composite 
Pattern is really in MVC. Is it really 
there? 


A: Yes, Virginia, there really is a 
Composite Pattern in MVC. But, actually, 
this is a very good question. Today GUI 
packages, like Swing, have become so 
sophisticated that we hardly notice the 
internal structure and the use of composite 
in the building and update of the display. 
It's even harder to see when we have Web 
browsers that can take markup language 
and convert it into a user interface. 


Back when MVC was first discovered, 
creating GUIs required a lot more manual 
intervention and the pattern was more 
obviously part of the MVC. 


Q: Does the controller ever 
implement any application logic? 


A: No, the controller implements 
behavior for the view. It is the smarts 

that translates the actions from the view 

to actions on the model. The model 

takes those actions and implements the 
application logic to decide what to do in 
response to those actions. The controller 
might have to do a little work to determine 
what method calls to make on the model, 
but that’s not considered the “application 
logic.” The application logic is the code that 
manages and manipulates your data and it 
lives in your model. 


Q: I’ve always found the word 
“model” hard to wrap my head around. 
| now get that it’s the guts of the 
application, but why was such a vague, 
hard-to-understand word used to 
describe this aspect of the MVC? 
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DumbQOuestions 


A: When MVC was named they needed 
a word that began with a “M” or otherwise 
they couldn't have called it MVC. 


But seriously, we agree with you, everyone 
scratches their head and wonders what a 
model is. But then everyone comes to the 
realization that they can’t think of a better 
word either. 


Q: You've talked a lot about the state 
of the model. Does this mean it has the 
State Pattern in it? 


A: No, we mean the general idea of 
state. But certainly some models do use the 
State Pattern to manage their internal states. 


(): I've seen descriptions of the MVC 
where the controller is described as a 
“mediator” between the view and the 
model. Is the controller implementing the 
Mediator Pattern? 


+ We haven't covered the Mediator 
Pattern (although you'll find a summary of 
the pattern in the appendix), so we won't go 
into too much detail here, but the intent of 
the mediator is to encapsulate how objects 
interact and promote loose coupling by 
keeping two objects from referring to each 
other explicitly. So, to some degree, the 
controller can be seen as a mediator, since 
the view never sets state directly on the 
model, but rather always goes through the 
controller. Remember, however, that the 
view does have a reference to the model to 
access its state. If the controller were truly a 
mediator, the view would have to go through 
the controller to get the state of the model 
as well. 


compound patterns 


* Does the view always have to ask 
the model for its state? Couldn’t we use 
the push model and send the model’s 
state with the update notification? 


A: Yes, the model could certainly send 
its state with the notification, and in fact, if 
you look again at the JSP/HTML view, that’s 
exactly what we're doing. We’re sending 
the entire model in a bean, which the view 
uses to access the state it needs using the 
bean properties. We could do something 
similar with the BeatModel by sending just 
the state that the view is interested in. If you 
remember the Observer Pattern chapter, 
however, you'll also remember that there’s a 
couple of disadvantages to this. If you don’t 
go back and have a second look. 


Q: If | have more than one view, do | 
always need more than one controller? 


A: Typically, you need one controller 
per view at runtime; however, the same 


controller class can easily manage many 
views. 


+ The view is not supposed to 
manipulate the model, however | noticed 
in your implementation that the view has 
full access to the methods that change 
the model’s state. Is this dangerous? 


A: You are correct; we gave the view 
full access to the model’s set of methods. 
We did this to keep things simple, but there 
may be circumstances where you want to 
give the view access to only part of your 
model's API. There’s a great design pattern 
that allows you to adapt an interface to only 
provide a subset. Can you think of it? 
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Tools for your Design Toolbox 


You could impress anyone with your design toolbox. 


Wow, look at all those principles, patterns and now, 
compound patterns! 


00 Principles 


Encapsvlate what varies: 
1 


mheritance: 


not 


composition oes Q Nostraction 
Emeapsulavien 
Patymorghism 


nneritance 


Favor 
Program to inberkacess 
implement acions 


S1OQNS 
ve kor loosely coupled desig) 


ca be that nteraet 


between objet 


on extension 
en 
Classes should be °F fieation 


Geb tlosed for yor 


don gostrattions: Do not 


Deven ke classes: 


devend 

only talk te Yor Friends: 
A 

welll call you 


on contre 


Dont call vs 


d class should have only one reason 


ko change 


00 Patterns 


We have a new 
de a suvro category: 

; hola nether object and Model 2 are 

e \aceho! “fh, Ss atterns. 
it ae access tot compound P n 
\e 

Compound Patterns 
= combines two or 
Compound coo jon that 
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= The Adapter Pattern can be 


= The Model View Controller 
Pattern (MVC) is a compound 
pattern consisting of the 
Observer, Strategy and 
Composite patterns. 


= The model makes use of the 
Observer Pattern so that it can 
keep observers updated yet 
stay decoupled from them. 


= The controller is the strategy 
for the view. The view can use 
different implementations of 
the controller to get different 
behavior. 


The view uses the Composite 
Pattern to implement the 

user interface, which usually 
consists of nested components 
like panels, frames and 
buttons. 


These patterns work together 
to decouple the three players in 
the MVC model, which keeps 
designs clear and flexible. 


used to adapt a new model to 
an existing view and controller. 


Model 2 is an adaptation of 
MVC for web applications. 


In Model 2, the controller is 
implemented as a servlet and 
JSP & HTML implement the 
view. 


compound patterns 


SEY Exercise solutions 


@esharpen your pencil 
ee yer P 


The QuackCounter is a Quackable too. When we change Quackable to extend 
QuackObservable, we have to change every class that implements Quackable, 
including QuackCounter: 


1 kable, so 
QuackCounter is a Quat' 
now it’s a QuackObservable too. 


public class QuackCounter implements Quackable { 
Quackable duck; 


static int numberOfQuacks; Here’s the duck that the 
QuackCounter is decorating, 
public QuackCounter (Quackable duck) { It’s this duck that reall 
this.duck = duck; needs to handle the 
} observable methods. 


public void quack() { 


duck. quack (); . . same 
numberOfQuacks+tt+; AM of this code is ue S 
} as the previous version 


QuatkCounter- 


public static int getQuacks() { 
return numberOfQuacks; 


} 


{ 


public void registerObserver (Observer observer) 
duck. registerObserver (observer) ; 


Here are the two 


} 


QuackObservable 
public void notifyObservers() { fe methods. Notice that 
duck.notifyObservers(); we just delegate both 
} calls to the duck that 


we're decorating, 
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etry your pencil 
DR What if our Quackologist wants to observe an entire flock? What does that mean 
anyway? Think about it like this: if we observe a composite, then we’re observing 

everything in the composite. So, when you register with a flock, the flock composite 
makes sure you get registered with all its children, which may include other flocks. 


Flock is a Quackable, so now 
it’s a QuatkObservable too. 


public class Flock implements Quackable { ; 
ArrayList ducks = new ArrayList(); a Here’s the Quackables that 


are in the Flock. 
public void add(Quackable duck) { 


ducks.add(duck) ; 
} 


public void quack() { 
Iterator iterator = ducks.iterator(); 
while (iterator.hasNext()) { 
Quackable duck = (Quackable) iterator.next(); 


duck. quack (); When you register as an Observer 


with the Flock, you attually a 
| vo registered with everything that's 
hich is every 
public void registerObserver (Observer observer) { IN the nme OS ie 
Iterator iterator = ducks.iterator(); Quatkab ” ve 
while (iterator.hasNext()) { ie Ss 


Quackable duck = (Quackable) iterator.next(); 
duck. registerObserver (observer) ; We iterate through all the 


Quackables in the Flock and 
delegate the call to each 


| | | Quackable. [f the Quackable 
public void notifyObservers() { } is another Flock, it will do 
the same. 


} 


¢ Each Quackable does its own notification, 
so Flock doesn’t have to worry about it. 
This happens when Flock delegates quack() 
to each Quackable in the Flock. 
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iad your pencil 
a We're still directly instantiating Geese by relying on concrete classes. Can you write 
an Abstract Factory for Geese? How should it handle creating “goose ducks?” 


You could add a ereateGooseDuck() method to the existing Duek Factories. Ov, You 
could create a completely separate Factory for creating families of Geese. 


RS Design Class 


You've seen that the View and Controller together make use of the Strategy Pattern. Can you draw a 


class diagram of the two that shows this pattern? 
a? 
ontrollerinterface 


Cc 


<<interface>> r £ 
: ace 
Controllerinterface is the inter 
that all tontrete 


setBPM() “ol fn 
increaseBPM() eontrollers implement: 


decreaseBPM() This is the strategy 
yan inter’: ace. 


The view delegates 
behavior to the DJView 
controller. The controller 
behavior it 

createView() 
delegates is how to updateBPM() 
control the model updateBeat() 
based on user input. createControls() 
enableStopMenultem() 


disableStopMenultem( 
enableStartMenultem( 
disableStartMenultem() 
actionPerformed() 


Controller 


on We can plug in 
decreaseBPM() different controllers 
to provide different 
behaviors for the view. 


you arehere > 563 


ready-bake code: the dj application 


2 Here’s the complete implementation of the DJView. It shows all the 
Ready-bake Code MIDI code to generate the sound, and all the Swing components to 
create the view. You can also download this code at 
http://www.wickedlysmart.com. Have fun! 


package headfirst.combined.djview; 
public class DJTestDrive { 
public static void main (String[] args) { 


BeatModelInterface model = new BeatModel (); 
ControllerInterface controller = new BeatController (model); 


The Beat Model 


package headfirst.combined.djview; 


public interface BeatModelInterface { 
void initialize(); 


void on(); 

void off(); 

void setBPM(int bpm) ; 
int getBPM() ; 


void registerObserver (BeatObserver 0); 


void removeObserver (BeatObserver 0); 


void registerObserver (BPMObserver 0); 


void removeObserver (BPMObserver 0); 
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package headfirst.combined.djview; 


import javax.sound.midi.*; 
import java.util.*; 
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public class BeatModel implements BeatModellInterface, 
Sequencer sequencer; 
ArrayList beatObservers = new ArrayList(); 
ArrayList bpmObservers = new ArrayList (); 
int bpm = 90; 
// other instance variables here 
Sequence sequence; 
Track track; 


public void initialize() { 
setUpMidi (); 
buildTrackAndStart (); 


public void on() { 
sequencer.start(); 
setBPM(90); 


public void off() { 
setBPM(0); 
sequencer.stop(); 


public void setBPM(int bpm) { 
this.bpm = bpm; 
sequencer.setTempoInBPM(getBPM()); 
notifyBPMObservers (); 


public int getBPM() { 
return bpm; 


void beatEvent() { 
notifyBeatObservers (); 


public void registerObserver (BeatObserver o) { 
beatObservers.add(o); 


public void notifyBeatObservers() { 


M 


tal 


EventListener { 
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| 


E | Ready-bake Code 


for(int i = 0; i < beatObservers.size(); i++) { 
BeatObserver observer = (BeatObserver) beatObservers.get (i); 
observer.updateBeat (); 


public void registerObserver (BPMObserver o) { 
bpmObservers.add(o); 
} 


public void notifyBPMObservers() { 
for(int i = 0; i < bpmObservers.size(); itt) { 
BPMObserver observer = (BPMObserver) bpmObservers.get (i); 
observer.updateBPM () ; 


public void removeObserver(BeatObserver o) { 
int i = beatObservers.indexOf (0); 
if (1 >= 0) { 
beatObservers.remove (i); 


public void removeObserver(BPMObserver o) { 
int i = bpmObservers.indexOf (0) ; 
Lf (i S= OY -4 
bpmObservers. remove (i) ; 


public void meta (MetaMessage message) { 
if (message.getType() == 47) { 
beatEvent (); 
sequencer.start(); 
setBPM(getBPM()); 


public void setUpMidi() { 
try { 
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sequencer = MidiSystem.getSequencer (); 
sequencer.open(); 
sequencer.addMetaEventListener (this) ; 
sequence = new Sequence (Sequence. PPQ,4); 
track = sequence.createTrack (); 
sequencer.setTempoInBPM(getBPM()); 

} catch(Exception e) { 

e.printStackTrace(); 


public void buildTrackAndStart() { 
int[] trackList = {35, 0, 46, 0}; 


sequence.deleteTrack (null); 
track = sequence.createTrack(); 


a 


makeTracks (trackList) ; 
track.add(makeEvent (192,9,1,0,4)); 
try 


sequencer.setSequence (sequence) ; 
} catch(Exception e) { 
e.printStackTrace (); 


public void makeTracks(int[] list) { 


for (int i = 0; i < list.length; i++) { 
int key Leste [a] F 


if (key != 0) { 
track.add(makeEvent (144,9,key, 100, i)); 
track.add(makeEvent (128,9,key, 100, it+1)); 


public idiEvent makeEvent (int comd, int chan, int one, int two, int tick) { 
MidiEvent event = null; 
try { 


ShortMessage a = new ShortMessage(); 
a.setMessage(comd, chan, one, two); 
event = new MidiEvent(a, tick); 


} catch(Exception e) { 
e.printStackTrace(); 


} 


return event; 
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ready-bake code: view 
The View 


package headfirst.combined.djview; 


public interface BeatObserver { 
void updateBeat (); 


package headfirst.combined.djview; 


public interface BPMObserver { 
void updateBPM(); 


package headfirst.combined.djview; 


import java.awt.*; 
import java.awt.event.*; 
import javax.swing.*; 


public class DJView implements ActionListener, BeatObserver, BPMObserver { 
BeatModelInterface model; 
ControllerInterface controller; 
JFrame viewFrame; 

JPanel viewPanel; 

BeatBar beatBar; 

JLabel bpmOutputLabel; 

JFrame controlFrame; 

JPanel controlPanel; 

JLabel bpmLabel; 

JTextField bpmTextField; 

JButton setBPMButton; 

JButton increaseBPMButton; 

JButton decreaseBPMButton; 

JMenuBar menuBar; 

JMenu menu; 

JMenuItem startMenultem; 

JMenuItem stopMenulItem; 


public DJView(ControllerInterface controller, BeatModelInterface model) { 
this.controller = controller; 
this.model = model; 
model.registerObserver ( (BeatObserver) this) ; 
model.registerObserver ((BPMObserver) this) ; 
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public void createView() { 
// Create all Swing components here 
viewPanel = new JPanel (new GridLayout(1, 2)); 
viewFrame = new JFrame (“View”) ; 


viewFrame.setDefaultCloseOperation (JFrame.EXIT ON CLOSE) ; 


viewFrame.setSize(new Dimension(100, 80)); 


bpmOutputLabel = new JLabel (“offline”, SwingConstants.CENT 


beatBar = new BeatBar(); 
beatBar.setValue (0); 


JPanel bpmPanel = new JPanel (new Gridhayout(2, 1)); 


bpmPanel .add(beatBar) ; 
bpmPanel.add(bpmOutputLabel) ; 
viewPanel.add(bpmPanel) ; 


viewFrame.getContentPane().add(viewPanel, BorderLayout.C 


viewFrame.pack(); 
viewFrame.setVisible (true) ; 


public void createControls() { 
// Create all Swing components here 
JFrame.setDefaultLookAndFeelDecorated (true) ; 
controlFrame = new JFrame (“Control”); 
controlFrame.setDefaultCloseOperation (JFrame.! 
controlFrame.setSize(new Dimension(100, 80)); 


controlPanel = new JPanel (new GridLayout (1, 2 


menuBar = new JMenuBar(); 

menu = new JMenu(“DJ Control”); 
startMenultem = new JMenultem(“Start”); 
menu.add(startMenultem) ; 


ENT 


EXIT _ON_CLOS! 


ye 


startMenultem.addActionListener (new ActionListener() { 
public void actionPerformed(ActionEvent event) { 


controller.start(); 


})e 
stopMenulItem = new JMenuItem(“Stop”) ; 
menu.add(stopMenultem) ; 


stopMenuItem.addActionListener (new ActionListener() { 
public void actionPerformed(ActionEvent event) { 


controller.stop(); 
//opmOutputLabel.setText (“offline”) ; 


})e 
JMenultem exit = new JMenulItem(“Quit”); 
exit.addActionListener (new ActionListener() { 


public void actionPerformed(ActionEvent event) { 


System.exit (0); 


compound patterns 


you are here > 


569 


ready-bake code: view 


| Ready-bake Code 


menu.add (exit); 
menuBar.add(menu) ; 
controlFrame.setJMenuBar (menuBar) ; 


bpmTextField = new JTextField(2); 

bpmLabel = new JLabel (“Enter BPM:”, SwingConstants.RIGHT) ; 
setBPMButton = new JButton(“Set”); 
setBPMButton.setSize(new Dimension(10,40)); 
increaseBPMButton new JButton(“>>”); 

decreaseBPMButton = new JButton (“<<”); 
setBPMButton.addActionListener (this) ; 
increaseBPMButton.addActionListener (this) ; 
decreaseBPMButton.addActionListener (this) ; 


JPanel buttonPanel = new JPanel(new GridLayout(l, 2)); 


buttonPanel.add(decreaseBPMButton) ; 
buttonPanel.add(increaseBPMButton) ; 


JPanel enterPanel = new JPanel (new GridLayout(1, 2)); 
enterPanel.add(bpmLabel) ; 

enterPanel.add(bpmTextField) ; 

JPanel insideControlPanel = new JPanel (new GridLayout(3, 1)); 
insideControlPanel.add(enterPanel) ; 
insideControlPanel.add(setBPMButton) ; 
insideControlPanel.add(buttonPanel); 
controlPanel.add(insideControlPanel); 


bpmLabel.setBorder (BorderFactory.createEmptyBorder (5,5,5,5)); 
bpmOutputLabel.setBorder (BorderFactory.createEmptyBorder (5,5,5,5)); 


controlFrame.getRootPane().setDefaultButton(setBPMButton) ; 
controlFrame.getContentPane().add(controlPanel, BorderLayout.CENTER) ; 


controlFrame.pack (); 
controlFrame.setVisible (true); 


public void enableStopMenulItem() { 
stopMenultem.setEnabled (true) ; 


public void disableStopMenuItem() { 
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stopMenultem.setEnabled(false) ; 


public void enableStartMenuItem() { 
startMenulItem.setEnabled (true) ; 


public void disableStartMenuItem() { 
startMenuItem.setEnabled (false); 


public void actionPerformed(ActionEvent event) { 


if (event.getSource() == setBPMButton) 


int bpm = Integer.parselInt (bpmTextField.getText ()); 


controller.setBPM (bpm) 


} else if (event.getSourc 


, 


} else if (event.getSourc 
controller.decreaseBPM 


, 


( 
controller.increaseBPM ( 
( 
( 


public void updateBPM() { 
int bpm = model.getBPM() ; 


if (bpm == 0) { 
bpmOutputLabel.setText (“offline”) ; 

} else { 
bpmOutputLabel.setText (“Current BPM: 


public void updateBeat() { 
beatBar.setValue (100); 


} 


The Controller 


package headfirst.combined.djview; 


public interface ControllerInterface { 
void start(); 
void stop(); 
void increaseBPM() ; 
void decreaseBPM(); 
void setBPM(int bpm) ; 


== increaseBPMButton) { 


== decreaseBPMButton) { 


“ + model.getBPM()); 
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ready-bake code: controller 


package headfirst.combined.djview; 


public class BeatController implements ControllerInterface { 
BeatModelInterface model; 
DJView view; 


public BeatController(BeatModellInterface model) { 
this.model = model; 
view = new DJView(this, model); 
view.createView(); 
view.createControls(); 
view.disableStopMenultem() ; 
view.enableStartMenuItem(); 
model.initialize(); 


public void start() { 
model.on(); 
view.disableStartMenulItem() ; 
view.enableStopMenuItem() ; 


public void stop() { 
model.off(); 
view.disableStopMenultem () ; 
view.enableStartMenultem() ; 


public void increaseBPM() { 
int bpm = model.getBPM() ; 
model.setBPM(bpm + 1); 


public void decreaseBPM() { 
int bpm = model.getBPM(); 
model.setBPM(bpm - 1); 


public void setBPM(int bpm) { 
model.setBPM (bpm) ; 
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The Heart Model 


package headfirst.combined.djview; 
public class HeartTestDrive { 
public static void main (String[] args) { 


HeartModel heartModel = new HeartModel (); 
ControllerInterface model = new HeartController(heartModel) ; 


package headfirst.combined.djview; 


public interface HeartModelInterface { 
int getHeartRate(); 
void registerObserver (BeatObserver 0); 
void removeObserver (BeatObserver 0); 
void registerObserver (BPMObserver 0); 
void removeObserver (BPMObserver 0); 


package headfirst.combined.djview; 
import java.util.*; 


public class HeartModel implements HeartModelInterface, Runnable { 
ArrayList beatObservers = new ArrayList(); 
ArrayList bpmObservers = new ArrayList (); 
int time = 1000; 
int bpm = 90; 
Random random = new Random(System.currentTimeMillis()); 
Thread thread; 


public HeartModel() { 
thread = new Thread(this); 
thread.start(); 


public void run() { 
int lastrate = -1; 


for(;;) { 
int change = random.nextInt (10); 
if (random.nextInt(2) == 0) { 
change = 0 - change; 
} 
int rate = 60000/ (time + change); 
if (rate < 120 && rate > 50) { 
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ready-bake code: heart beat model 


time += change; 

notifyBeatObservers (); 

if (rate != lastrate) { 
lastrate = rate; 
notifyBPMObservers(); 


} 
try’ 

Thread.sleep (time) ; 
} catch (Exception e) {} 


} 
public int getHeartRate() { 
return 60000/time; 


public void registerObserver (BeatObserver o) { 
beatObservers.add(o); 


public void removeObserver(BeatObserver o) { 
int i = beatObservers.indexOf (0); 
LE (i S=0)~ 4 
beatObservers.remove (i); 


public void notifyBeatObservers() { 
for(int i = 0; i < beatObservers.size(); i++) { 
BeatObserver observer = (BeatObserver) beatObservers.get (i); 


observer.updateBeat (); 


public void registerObserver (BPMObserver o) { 
bpmObservers.add(o); 


public void removeObserver(BPMObserver o) { 
int i = bpmObservers.indexOf (0) ; 
if (1. 5= 0) { 
bpmObservers. remove (i) ; 


public void notifyBPMObservers() { 
for(int i = 0; i < bpmObservers.size(); itt) { 
BPMObserver observer = (BPMObserver) bpmObservers.get (i); 
observer.updateBPM () ; 


} 
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The Heart Adapter 


package headfirst.combined.djview; 


public class HeartAdapter implements BeatModelInterface { 
HeartModelInterface heart; 


public HeartAdapter (HeartModellInterface heart) { 
this.heart = heart; 


public void initialize() {} 
public void on() {} 
public void off() {} 


public int getBPM() { 
return heart.getHeartRate(); 


public void setBPM(int bpm) {} 


public void registerObserver (BeatObserver o) { 
heart.registerObserver (0) ; 


public void removeObserver(BeatObserver o) { 
heart. removeObserver (0); 


public void registerObserver (BPMObserver o) { 
heart.registerObserver (0) ; 


public void removeObserver(BPMObserver o) { 
heart.removeObserver (0); 
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ready-bake code: heart beat controller 


The Controller 


package headfirst.combined.djview; 


public class HeartController implements ControllerInterface { 
HeartModeliInterface model; 
DJView view; 


public HeartController(HeartModelInterface model) { 
this.model = model; 
view = new DJView(this, new HeartAdapter (model) ); 
view.createView(); 
view.createControls(); 
view.disableStopMenultem() ; 
view.disableStartMenulItem() ; 


public void start() {} 
public void stop() {} 
public void increaseBPM() {} 


public void decreaseBPM() {} 


public void setBPM(int bpm) {} 
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13 Better Living with Patterns 


+ 
Patterns inthe * 
* Real World” 


Ahhhh, now you’re ready for a bright new world filled with 
Design Patterns. But, before you go opening all those new doors of opportunity, we 
need to cover a few details that you'll encounter out in the real world — that’s right, things get 
a little more complex than they are here in Objectville. Come along, we've got a nice guide to 
help you through the transition on the next page... 
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wh earn fro e guiae 


The Objectville Guide to e > 


[Setter Living with Design Patteuns 


Please accept out handy quide with tips & tricks for living with patteuns in the wal 
world. Jn this quide you will 


wy Lean the all too common misconceptions about the definition of a 
“Design Pattern. ‘ 


uy Discovet those nifty Design Pattern Catalogs and why you just have to 


get one. 


ear Avoid the embarrassment of using @ Design Pattern at the wrong tune- 


vy Learn how to keep patterns mn classifications where they belong. 


ur See that discovetng patterns isn t just for the gus: wad out quick 


HowTo and. hecome a patteuns writer too. 


x Be there when the tue identity of the mystewous Gang of Four is revealed. 


Lae Keep up with the neighbors - the coffee table hooks any patteus uset 


must own. 


xr Leann to train your mind like a Zen master. 


x Wa fiends and influence developets by improving yout pattens 


vocabu ty. 
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better living with patterns 
Design Pattern defined 


We bet you've got a pretty good idea of what a pattern is after reading this book. But 
we've never really given a definition for a Design Pattern. Well, you might be a bit 
surprised by the definition that is in common use: 


A Pattern is a solution to a problem in a context. 


That’s not the most revealing definition is it? But don’t worry, we’re going to step 
through each of these parts, context, problem and solution: 


Example: You have 8 
a tollection of objects. 


The context is the situation in which the pattern applies. This 


- eae You need to step 
should be a recurring situation. through the obje ne 
The problem refers to the goal you are trying to achieve in this without exposing the 
context, but it also refers to any constraints that occur in the colleetion’s imple— 
context. mentation. 

The solution is what you’re after: a general design that anyone 
can apply which eee the goal af set of oe . ee Encapsulate the 


iteration into a 
separate Class. 


This is one of those definitions that takes a while to sink in, but take it one step at a 
time. Here’s a little mnemonic you can repeat to yourself to remember it: 


“If You find yourself in a Context with a problem that has a goal 
that is affected by a set of constraints, then you can apply 
a design that resolves the goal and constraints and leads to a 


solution.” 


Now, this seems like a lot of work just to figure out what a Design Pattern is. After all, 
you already know that a Design Pattern gives you a solution to a common recurring 
design problem. What is all this formality getting you? Well, you’re going to see that 


by having a formal way of describing patterns we can create a catalog of patterns, 
which has all kinds of benefits. 
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I've been thinking 
about the three-part 
definition, and I don't think 
it defines a pattern at all. 


You might be right; let’s think about this a bit... We need a problem, a 
Solution and a context: 


Problem: How do I get to work on time? 
Context: I’ve locked my keys in the car. 


Solution: Break the window, get in the car, start 
the engine and drive to work. 


We have all the components of the definition: we have a problem, 
which includes the goal of getting to work, and the constraints of time, 
distance and probably some other factors. We also have a context in 
which the keys to the car are inaccessible. And we have a solution that 
gets us to the keys and resolves both the time and distance constraints. 
We must have a pattern now! Right? 


oe RAIN 
POWER 
We followed the Design Pattern definition and defined a problem, a context, and a solution (which 


works!). Is this a pattern? If not, how did it fail? Could we fail the same way when defining an OO 
Design Pattern? 
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Looking more closely at the 
Design Pattern definition 


Our example does seem to match the Design 
Pattern definition, but it isn’t a true pattern. Why? 
For starters, we know that a pattern needs to apply 
to a recurring problem. While an absent-minded 
person might lock his keys in the car often, breaking 


the car window doesn’t qualify as a solution that 


can be applied over and over (or at least isn’t likely 


to if we balance the goal with another constraint: 


cost). 


It also fails in a couple of other ways: first, it isn’t 


easy to take this description, hand it to someone 


and have him apply it to his own unique problem. 


Second, we’ve violated an important but simple 


aspect of a pattern: we haven’t even given it a 


name! Without a name, the pattern doesn’t 


become part of a vocabulary that can be shared 


with other developers. 


Luckily, patterns are not described and documented 


as a simple problem, context and solution; we 


have much better ways of describing patterns and 


collecting them together into patterns catalogs. 


- Am| going to see pattern 
descriptions that are stated as a problem, 
a context and a solution? 


: Pattern descriptions, which you'll 
typically find in pattern catalogs, are usually 
a bit more revealing than that. We're going 
to look at pattern catalogs in detail in just 
a minute; they describe a lot more about a 
pattern’s intent and motivation and where it 
might apply, along with the solution design 
and the consequences (good and bad) of 
using it. 


Q: Is it okay to slightly alter a 
pattern’s structure to fit my design? Or 
am | going to have to go by the strict 
definition? 


A: Of course you can alter it. Like 
design principles, patterns are not meant 
to be laws or rules; they are guidelines that 
you can alter to fit your needs. As you've 
seen, a lot of real-world examples don't fit 
the classic pattern designs. 


However, when you adapt patterns, it 
never hurts to document how your pattern 
differs from the classic design — that way, 
other developers can quickly recognize the 
patterns you're using and any differences 
between your pattern and the classic 
pattern. 


Next time someone tells you 
a pattern is a solution to a problem 
ina context, just nod and smile. You 
know what they mean, even if it isn't a 
definition sufficient to describe what 
a Design Pattern really is. 
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Q: 


catalog? 


Where can | get a patterns 


A: The first and most definitive 
patterns catalog is Design Patterns: 
Elements of Reusable Object-Oriented 
Software, by Gamma, Helm, Johnson & 
Vlissides (Addison Wesley). This catalog 
lays out 23 fundamental patterns. We'll talk 
a little more about this book in a few pages. 


Many other patterns catalogs are starting to 
be published in various domain areas such 

as enterprise software, concurrent systems 

and business systems. 
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constraints 


May the force be with you 


> 
p \ Geek Bits 
The Design Pattern 
definition tells us that 
the problem consists of a 
goalanda setofconstraints. 
Patterns gurus have a term 
for these: they call them 
forces. Why? Well, we’re sure 
they have their own reasons, but if 
you remember the movie, the force 
“shapes and controls the Universe.” 
Likewise, the forces in the pattern 
definition shape and control the solution. 
Only when a solution balances both sides of 
the force (the light side: your goal, and the dark 
side: the constraints) dowe have auseful pattern. 


This “force” terminology can be quite confusing 
when you first see it in pattern discussions, but 
just remember that there are two sides of the force 

(goals and constraints) and that they need to be 
balanced or resolved to create a pattern solution. Don't 
let the lingo get in your way and may the force be with you! 


I wish I'd known about 
patterns catalogs a long 
time ago... 


Frank: Fill us in, Jim. I’ve just been learning patterns by reading a 
few articles here and there. 


Jim: Sure, each pattern catalog takes a set of patterns and describes 
each in detail along with its relationship to the other patterns. 


Joe: Are you saying there is more than one patterns catalog? 


Jim: Of course; there are catalogs for fundamental Design Patterns 
and there are also catalogs on domain specific patterns, like EJB 
patterns. 


Frank: Which catalog are you looking at? 


Jim: This is the classic GoF catalog; it contains 23 fundamental 
Design Patterns. 


Frank: GoF? 

Jim: Right, that stands for the Gang of Four. The Gang of Four are 
the guys that put together the first patterns catalog. 

Joe: What’s in the catalog? 


Jim: There is a set of related patterns. For each pattern there is a 
description that follows a template and spells out a lot of details of the 
pattern. For instance, each pattern has a name. 
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Frank: Wow, that’s earth-shattering — a name! Imagine that. 


Jim: Hold on Frank; actually, the name is really important. When we have a name 
for a pattern, it gives us a way to talk about the pattern; you know, that whole shared 
vocabulary thing. 


Frank: Okay, okay. I was just kidding. Go on, what else is there? 


Jim: Well, like I was saying, every pattern follows a template. For each pattern we have 

a name and a few sections that tell us more about the pattern. For instance, there is an 
Intent section that describes what the pattern is, kind of like a definition. Then there are 
Motivation and Applicability sections that describe when and where the pattern might be 
used. 


Joe: What about the design itself? 


Jim: There are several sections that describe the class design along with all the classes 
that make it up and what their roles are. There is also a section that describes how to 
implement the pattern and often sample code to show you how. 


Frank: It sounds like they’ve thought of everything. 


Jim: There’s more. There are also examples of where the pattern has been used in real 
systems as well as what I think is one of the most useful sections: how the pattern relates 
to other patterns. 


Frank: Oh, you mean they tell you things like how state and strategy differ? 
Jim: Exactly! 


Joe: So Jim, how are you actually using the catalog? When you have a problem, do you 
go fishing in the catalog for a solution? 


Jim: I try to get familiar with all the patterns and their relationships first. ‘Then, when I 
need a pattern, I have some idea of what it is. I go back and look at the Motivation and 
Applicability sections to make sure I’ve got it right. There is also another really important 
section: Consequences. I review that to make sure there won’t be some unintended effect 
on my design. 


Frank: That makes sense. So once you know the pattern is right, how do you approach 
working it into your design and implementing it? 


Jim: That’s where the class diagram comes in. I first read over the Structure section to 
review the diagram and then over the Participants section to make sure I understand each 
classes’ role. From there I work it into my design, making any alterations I need to make 
it fit. Then I review the Implementation and Sample code sections to make sure I know 
about any good implementation techniques or gotchas I might encounter. 


Joe: I can see how a catalog is really going to accelerate my use of patterns! 


Frank: Totally. Jim, can you walk us through a pattern description? 
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‘ P< Cary 
All patterns in a catalog start SNOLETON Oberon e—, Hhis is the pattern’s 
with a name. The name is a vital ifigation o 


e 
part of a pattern — without a Sa eG a nx am do ein category. We'll talk 
good name, a pattern can't become about these in a 


part of the vocabulary that you 
share with other developers. 


The motivation gives you a tontreteé 
stenario that describes the problem and 
how the solution solves the problem. Va 


ew Pages. 


The intent deseribes what 
the pattern does in a short 
statement. You ean also think 
of this as the pattern’s 
definition Gust like we've been 
using in this book). 


“er immo dolorem, 
mca am quate magnim illam zzrit ad magna feu facinit delit ut 


The applicability destribes situations 


tt, be applied = 
inowhi can be applied. hee 
im which the pattern an F [tema — The steutiure provides a 
Participants diagram illustrating, the 
\ and Duis nalpatem iis exccte con . relationships among the 
The participants a me ein classes that participate 
objects in the design. Rls *e a in the pattern. 
deseribes their responsibilities an aa 
alas in the P attern. ee — Dui blaore min ca feuipit ing enit 
laore magnibh eniat wisissecte et, susclla ad mincinci blam dolorpe reilit & 
Consequences Collaborations tells us 
The Consequences describe the Duis pts cc ont ice nan lg ames how the Participants work 
effeets that using this pattern together in the pattern. 
may have: good and bad. 
Implementation provides ———? 
techniques you need to use when Fa le code 
implementing this pattern, and Sl code 
issues You should wateh out for. ragments that 
might help with 


Your implementat on. 


Known uses describes “ y 
examples of this pattern pas ses a 
found in veal systems. i 


lamet, conullandre 


d c 
deseribes the 
relationship between 
this pattern and others. 
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the ‘eyare No 
Dumb Questions 


Q: Is it possible to create your own Design 
Patterns? Or is that something you have to be a 
“patterns guru” to do? 


A: First, remember that patterns are discovered, 
not created. So, anyone can discover a Design Pattern 
and then author its description; however, it’s not easy 
and doesn’t happen quickly, nor often. Being a “patterns 
writer” takes commitment. 


You should first think about why you'd want to - the 
majority of people don’t author patterns; they just use 
them. However, you might work in a specialized domain 
for which you think new patterns would be helpful, or 
you might have come across a solution to what you 
think is a recurring problem, or you may just want to get 
involved in the patterns community and contribute to the 
growing body of work. 


Q: I’m game; how do | get started? 


A: Like any discipline, the more you know the 
better. Studying existing patterns, what they do and 
how they relate to other patterns is crucial. Not only 
does it make you familiar with how patterns are crafted, 
it prevents you from reinventing the wheel. From there 
you'll want to start writing your patterns on paper, so you 
can communicate them to other developers; we're going 
to talk more about how to communicate your patterns in 
a bit. If you’re really interested, you'll want to read the 
section that follows these Q&As. 


Q: How do | know when | really have a pattern? 


A: That's a very good question: you don’t have a 
pattern until others have used it and found it to work. 

In general, you don’t have a pattern until it passes the 
“Rule of Three.” This rule states that a pattern can be 
called a pattern only if it has been applied in a real-world 
solution at least three times. 


So you wanna be a design 
patterns star? 


Well listen now to what | tell. 


Get —_ a patterns 
catalog, 


Then take some time and 
learn it well. 


And when you've got your 
description right, 


And three developers agree 
without a fight, 


Then you'll know it’s a 
pattern alright. 


To the tune of “So you wanna 
bea Rotk'n Roll Star. 


So you wanna be a Design Patterns writer 


Do your homework. You need to be well versed in the 
existing patterns before you can create a new one. Most patterns 
that appear to be new, are, in fact, just variants of existing 
patterns. By studying patterns, you become better at recognizing 
them, and you learn to relate them to other patterns. 


Take time to reflect, evaluate. Your experience — the 
problems you’ve encountered, and the solutions you’ve used — are 
where ideas for patterns are born. So take some time to reflect 
on your experiences and comb them for novel designs that recur. 
Remember that most designs are variations on existing patterns 
and not new patterns. And when you do find what looks like a 
new pattern, its applicability may be too narrow to qualify as a 
real pattern. 


Get your ideas down on paper in a way others can 
understand. Locating new patterns isn’t of much use if others 
can’t make use of your find; you need to document your pattern 
candidates so that others can read, understand, and apply them 
to their own solution and then supply you with feedback. Luckily, 
you don’t need to invent your own method of documenting your 
patterns. As you’ve already seen with the GoF template, a lot of 
thought has already gone into how to describe patterns and their 
characteristics. 


Have others try your patterns; then refine and refine 
some more. Don’t expect to get your pattern right the first 
time. Think of your pattern as a work in progress that will 
improve over time. Have other developers review your candidate 
pattern, try it out, and give you feedback. Incorporate that 
feedback into your description and try again. Your description 
will never be perfect, but at some point it should be solid enough 
that other developers can read and understand it. 


Don’t forget the rule of three. Remember, unless your 
pattern has been successfully applied in three real-world 
solutions, it can’t qualify as a pattern. That’s another good 
reason to get your pattern into the hands of others so they can 
try it, give feedback, and allow you to converge on a working 
pattern. 
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Use one of the existing 
pattern templates to 
define your pattern: 

lot of thought has gone 
into these templates and 
other pattern users will 
recognize the format. 


Nae 
tew 
Nativation 
Applicability 
grructure 
Participants 
Collaborations 
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who does 


+9 


as 
WHE DOES wHarT? 


Match each pattern with its description: 
Pattern Description 
Paco Wraps an object and provides a different 
interkace to it. 


Subclasses decide how to im plement steps 
in an algorithm. 


Subclassesdecide whichconcreteclassesto 
create. 


Ensures one and only object is created. 


Encapsulatesinterchangeablebehaviorsand 
uses delegation te decide Which one te use. 


Clients treat collections of objects and 
individual objects uniformly. 


Encapsulatesstate-basedbehaviorsanduses 
delegation to switch between behaviors. 


Provides a way to traverse a collection of 
Observer objectswithoutexposing itsimplementation. 
TemplateMethod Simplifies the interface of a set of classes. 
Wraps an object to provide new behavior. 


Composite Allows aclientte create families of objects 
without specifying their concrete classes. 


Allows objects to be notified when state 


Abstract Factory changes. 
Wraps an object to contro] access +o it. 


Command Eneapsulates a request as an object. 


State 
lterator 


Facade 


Singleton 
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Organizing Design Patterns 


As the number of discovered Design Patterns grows, it makes sense to partition them into classifications so 
that we can organize them, narrow our searches to a subset of all Design Patterns, and make comparisons 
within a group of patterns. 


In most catalogs you'll find patterns grouped into one of a few classification schemes. The most well-known 
scheme was used by the first pattern catalog and partitions patterns into three distinct categories based on 
their purposes: Creational, Behavioral and Structural. 


Ce harpen your pencil 


Read each category description and see 
if you can corral these patterns into their 

+ Factor Observe ; igs 
aca u Composite : [strategy | —_ correct categories. This is a toughy! But 


give it your best shot and then check out 


the answers on the next page. 
Template Method 


of these patterns belongs 
categories 


Any pattern that is a Behavioral 
Pattern is concerned with how 
classes and objects interact and 
distribute responsibility. 


Creational patterns involve 
object instantiation and all 
provide a way to decouple a client 
from the objects it needs to 
instantiate. 


Creational Behavioral 


Structural 


Structural patterns let you 
compose classes or objects 
into larger structures. 
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Solution: Pattern Categories 


Here’s the grouping of patterns into categories. You probably found the exercise difficult, 
because many of the patterns seem like they could fit into more than one category. Don’t worry, 
everyone has trouble figuring out the right categories for the patterns. 


Creational patterns involve 
object instantiation and all 
provide a way to decouple a client 
from the objects it needs to 


Any pattern that is a Behavioral 
Pattern is concerned with how 
classes and objects interact and 
distribute responsibility. 


instantiate. 
Creational Behavioral 
; Mediat 
Singleton Builder Template Method Visitor cores 
Prototype i Bevo 
Abstract Factory Interpreter ora, premente 
Factory Method F eee wel 
Y Chain of Responsibility 
State 
Strate 
Structural a 
Proxy 
Decorator 
Composite Facade 
Flyweight Bridge 
Adapter 


We've got a few patterns 
(in grey) that you haven't 


seen yet: You'll find an 
overview of the these 
patterns in the appendix. 


Structural patterns let you 
compose classes or objects 


into larger structures. 
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Patterns are often classified by a second attribute: whether or not 
the pattern deals with classes or objects: 


Class patterns describe how relationships between 
classes are defined via inheritance. Relationships in 
class patterns are established at compile time. 


Class 


Template Method 


Factory Method Adapter 


Interpreter 


: Are these the only classification 
schemes? 


A: No, other schemes have been 
proposed. Some other schemes start 

with the three categories and then add 
subcategories, like “Decoupling Patterns.” 
You'll want to be familiar with the most 
common schemes for organizing patterns, 
but also feel free to create your own, if it 
helps you to understand the patterns better. 


* Does organizing patterns into 
categories really help you remember 
them? 


Object 


Composite 


Decorator 
Proxy Facade 


Strategy 


Bridge Mediator 


Flyweight Prototype 


Abstract Factory 
Singleton 
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Dumb Questions 


A: It certainly gives you a framework 
for the sake of comparison. But many 
people are confused by the creational, 
structural and behavioral categories; often 
a pattern seems to fit into more than one 
category. The most important thing is to 
know the patterns and the relationships 
among them. When categories help, use 
them! 


: Why is the Decorator Pattern in 
the structural category? | would have 
thought of that as a behavioral pattern; 
after all it adds behavior! 


Visitor 
Iterator 
Command 


Builder 
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Object patterns describe 
relationships between 
objects and are primarily 
defined by composition. 
Relationships in object 
patterns are typically 
created at runtime and 
are more dynamic and 
flexible. 


Memento 


Observer 
Chain of Responsibility 


State 


Notice bheve's 2 
Jot more objet 
patterns than 
el ass patterns. 


= Yes, lots of developers say that! 
Here's the thinking behind the Gang of Four 
Classification: structural patterns describe 
how classes and objects are composed to 
create new structures or new functionality. 
The Decorator Pattern allows you to 
compose objects by wrapping one object 
with another to provide new functionality. 
So the focus is on how you compose the 
objects dynamically to gain functionality, 
rather than on the communication and 
interconnection between objects, which 
is the purpose of behavioral patterns. But 
remember, the intent of these patterns 
is different, and that’s often the key to 
understanding which category a pattern 
belongs to. 
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Master and Student... 
bem Master: Grasshopper, you look troubled. 


Student: Yes, I’ve just learned about 
pattern classification and I’m confused. 


Master: Grasshopper, continue... 


Student: After learning much about patterns, I’ve 

just been told that each pattern fits into one of three 
classifications: structural, behavioral or creational. Why 
do we need these classifications? 


Master: Grasshopper, whenever we have a large 
collection of anything, we naturally find categories to fit 
those things into. It helps us to think of the items at a 
more abstract level. 


Student: Master; can you give me an example? 


Master: Of course. Take automobiles; there are many 
different models of automobiles and we naturally put 
them into categories like economy cars, sports cars, 
SUVs, trucks and luxury car categories. 


Master: Grasshopper, you look shocked, does this not 
make sense? 


Student: Master, it makes a lot of sense, but | am 
shocked you know so much about cars! 


Master: Grasshopper, | can’t relate everything to lotus 
flowers or rice bowls. Now, may | continue? 


Student: Yes, yes, I’m sorry, please continue. 


Master: Once you have classifications or categories 
you can easily talk about the different groupings: “If 
you're doing the mountain drive from Silicon Valley to 
Santa Cruz, a sports car with good handling is the best 
option.” Or, “With the worsening oil situation you really 
want to buy a economy car, they're more fuel-efficient.” 


Student: So by having categories we can talk about a 
set of patterns as a group. We might know we need a 
creational pattern, without knowing exactly which one, 
but we can still talk about creational patterns. 


Master: Yes, and it also gives us a way to compare a 
member to the rest of the category, for example, “the 
Mini really is the most stylish compact car around”, or 
to narrow our search, “I need a fuel efficient car.” 
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Student: | see, so | might say that the Adapter pattern 
is the best structural pattern for changing an object’s 
interface. 


Master: Yes. We also can use categories for one more 
purpose: to launch into new territory; for instance, 

“we really want to deliver a sports car with ferrari 
performance at miata prices.” 


Student: That sounds like a death trap. 
Master: I’m sorry, | did not hear you Grasshopper. 
Student: Uh, | said “I see that.” 


Student: So categories give us a way to think about the 
way groups of patterns relate and how patterns within 

a group relate to one another. They also give us a way 
to extrapolate to new patterns. But why are there three 
categories and not four, or five? 


Master: Ah, like stars in the night sky, there are as many 
categories as you want to see. Three is a convenient 
number and a number that many people have decided 
makes for a nice grouping of patterns. But others have 
suggested four, five or more. 
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Thinking in Patterns 


Contexts, constraints, forces, catalogs, classifications... boy, this 
is starting to sound mighty academic. Okay, all that stuff is 
important and knowledge zs power. But, let’s face it, if you 
understand the academic stuff and don’t have the experience 
and practice using patterns, then it’s not going to make much 
difference in your life. 


Here’s a quick guide to help you start to think in patterns. What do 
. Your Brain on Patterns 


we mean by that? We mean being able to look at a design and see 
where patterns naturally fit and where they don’t. 


Keep it simple (KISS) 


First of all, when you design, solve things in the simplest way possible. Your goal should be simplicity, not 
“how can I apply a pattern to this problem.” Don’t feel like you aren’t a sophisticated developer if you 
don’t use a pattern to solve a problem. Other developers will appreciate and admire the simplicity of your 
design. That said, sometimes the best way to keep your design simple and flexible is to use a pattern. 


Design Patterns aren't a magic bullet: in fact they're not even a bullet! 


Patterns, as you know, are general solutions to recurring problems. Patterns also have the benefit of being 
well tested by lots of developers. So, when you see a need for one, you can sleep well knowing many 
developers have been there before and solved the problem using similar techniques. 


However, patterns aren’t a magic bullet. You can’t plug one in, compile and then take an early lunch. ‘To 
use patterns, you also need to think through the consequences on the rest of your design. 


You know you need a pattern when... 


Ah... the most important question: when do you use a pattern? As you approach your design, introduce a 
pattern when you're sure it addresses a problem in your design. If a simpler solution might work, give that 
consideration before you commit to using a pattern. 


Knowing when a pattern applies is where your experience and knowledge come in. Once you're sure a 
simple solution will not meet your needs, you should consider the problem along with the set of constraints 
under which the solution will need to operate — these will help you match your problem to a pattern. If 
you've got a good knowledge of patterns, you may know of a pattern that is a good match. Otherwise, 
survey patterns that look like they might solve the problem. The intent and applicability sections of the 
patterns catalogs are particularly useful for this. Once you’ve found a pattern that appears to be a good 
match, make sure it has a set of consequences you can live with and study its effect on the rest of your 
design. If everything looks good, go for it! 
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There is one situation in which you'll want to use a pattern even if a 
simpler solution would work: when you expect aspects of your system to 
vary. As we’ve seen, identifying areas of change in your design is usually a 
good sign that a pattern 1s needed. Just make sure you are adding patterns 
to deal with practical change that is likely to happen, not hypothetical change 
that may happen. 


Design time isn’t the only time you want to consider introducing patterns, 
you'll also want to do so at refactoring time. 


Refactoring time is Patterns time! 


Refactoring is the process of making changes to your code to improve 
the way it is organized. The goal is to improve its structure, not change 
its behavior. This is a great time to reexamine your design to see if it 
might be better structured with patterns. For instance, code that is full 
of conditional statements might signal the need for the State pattern. Or, 
it may be time to clean up concrete dependencies with a Factory. Entire 
books have been written on the topic of refactoring with patterns, and as 
your skills grow, you’ll want to study this area more. 


Take out what you don’t really need. Don't be afraid 
to remove a Design Pattern from your design. 


No one ever talks about when to remove a pattern. You’d think it was 
blasphemy! Nah, we’re all adults here; we can take it. 


Center your thinking 
on design, not on patterns. 
Use patterns when there 

is a natural need for them. 
If something simpler will 


work, then use it. 
So when do you remove a pattern? When your system has become 


complex and the flexibility you planned for isn’t needed. In other words, 
when a simpler solution without the pattern would be better. 


If you don’t need it now, don't do it now. 


Design Patterns are powerful, and it’s easy to see all kinds of ways 

they can be used in your current designs. Developers naturally love to 
create beautiful architectures that are ready to take on change from any 
direction. 


Resist the temptation. If you have a practical need to support change in 
a design today, go ahead and employ a pattern to handle that change. 
However, if the reason 1s only hypothetical, don’t add the pattern, it 1s 


only going to add complexity to your system, and you might never need it! 


you arehere > 595 


patterns emerge naturally 


Master: Grasshopper, your initial training is almost 
complete. What are your plans? 


Student: I’m going to Disneyland! And, then I’m 
going to start creating lots of code with patterns! 


Master: Whoa, hold on. Never use your big guns unless you have to. 


Student: What do you mean, Master? Now that I’ve learned design 
patterns shouldn't | be using them in all my designs to achieve 
maximum power, flexibility and manageability? 


Master: No; patterns are a tool, and a tool that should only be used 
when needed. You’ve also spent a lot of time learning design principles. 
Always start from your principles and create the simplest code you can 
that does the job. However, if you see the need for a pattern emerge, 
then use it. 


Student: So | shouldn't build my designs from patterns? 


Master: That should not be your goal when beginning a design. Let 
patterns emerge naturally as your design progresses. 


Student: If patterns are so great, why should | be so careful about 
using them? 


Master: Patterns can introduce complexity, and we never want 
complexity where it is not needed. But patterns are powerful when used 
where they are needed. As you already know, patterns are proven 
design experience that can be used to avoid common mistakes. They're 
also a shared vocabulary for communicating our design to others. 


Student: Well, when do we know it’s okay to introduce design patterns? 


Master: Introduce a pattern when you are sure it’s necessary to solve a 
problem in your design, or when you are quite sure that it is needed to 
deal with a future change in the requirements of your application. 


Student: | guess my learning is going to continue even though | already 
understand a lot of patterns. 


Master: Yes, grasshopper; learning to manage the complexity and 
change in software is a life long pursuit. But now that you know a good 
set of patterns, the time has come to apply them where needed in your 
design and to continue learning more patterns. 


Student: Wait a minute, you mean | don’t know them ALL? 


Master: Grasshopper, you’ve learned the fundamental patterns; you're 
going to find there are many more, including patterns that just apply to 
particular domains such as concurrent systems and enterprise systems. 
But now that you know the basics, you're in good shape to learn them! 
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Your Mind on Patterns 


The Beginner uses patterns everywhere. This is good: 
the beginner gets lots of experience with and practice using 
patterns. The beginner also thinks, “The more patterns | use, 
the better the design.” The beginner will learn this is not so, 
that all designs should be as simple as possible. Complexity 


BEGINNER MIND and patterns should only be used where they are needed for 


practical extensibility. 


“{ need a pattern for Hello World.” 


As learning progresses, the Intermediate mind 
starts to see where patterns are needed and 
where they aren’t. The intermediate mind still tries 
to fit too many square patterns into round holes, but 
also begins to see that patterns can be adapted to 
fit situations where the canonical pattern doesn't fit. 


INTERMEDIATE 
MIND 


“Maybe | need a Singleton here.” 


The Zen mind is able to see patterns where they fit naturally. 
The Zen mind is not obsessed with using patterns; rather it 
looks for simple solutions that best solve the problem. The Zen 
mind thinks in terms of the object principles and their trade-offs. 
When a need for a pattern naturally arises, the Zen mind applies 
ZEN MIND it knowing well that it may require adaptation. The Zen mind 
also sees relationships to similar patterns and understands the 
ene , subtleties of differences in the intent of related patterns. The 
This is a natural place for Decorator. Zen mind is also a Beginner mind — it doesn't let all that pattern 
knowledge overly influence design decisions. 


_ ar, {es ra 
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when not to use patterns 


WARNING: Overuse of design patterns can lead to code that 
is downright over-engineered, Always go with the simplest 


Solution that does the job and introdu 
ce pat 
emerges, patterns where the need 


Wait a minute; I've 
read this entire book and now 
you're telling me NOT to use 
patterns? 


Of course we want you to 
use Design Patterns! 


But we want you to be a good OO designer even 
more. 


When a design solution calls for a pattern, you get 
the benefits of using a solution that has been time 
tested by lots of developers. You’re also using a 
solution that is well documented and that other 
developers are going to recognize (you know, that 
whole shared vocabulary thing). 


However, when you use Design Patterns, there 
can also be a downside. Design Patterns often 
introduce additional classes and objects, and so 
they can increase the complexity of your designs. 
Design Patterns can also add more layers to your 
design, which adds not only complexity, but also 
inefficiency. 


Also, using a Design Pattern can sometimes be 
outright overkill. Many times you can fall back on 
your design principles and find a much simpler 
solution to solve the same problem. If that 
happens, don’t fight it. Use the simpler solution. 


Don’t let us discourage you, though. When a 
Design Pattern is the right tool for the job, the 
advantages are many. 
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Don't forget the power of the 
shared vocabulary 


We've spent so much time in this book discussing OO nuts and bolts that it’s 
easy to forget the human side of Design Patterns — they don’t just help load 
your brain with solutions, they also give you a shared vocabulary with other 
developers. Don’t underestimate the power of a shared vocabulary, it’s one of 
the biggest benefits of Design Patterns. 


Just think, something has changed since the last time we talked about shared 
vocabularies; you’ve now started to build up quite a vocabulary of your own! 
Not to mention, you have also learned a full set of OO design principles from 
which you can easily understand the motivation and workings of any new 
patterns you encounter. 


Now that you’ve got the Design Pattern basics down, it’s time for you to 
go out and spread the word to others. Why? Because when your fellow 
developers know patterns and use a shared vocabulary as well, it leads to 
better designs, better communication and, best of all, it'll save you a lot of 
time that you can spend on cooler things. 


So I created this broadcast class. It 
keeps track of all the objects listening to it 
and anytime a new piece of data comes along 
it sends a message to each listener. What's cool 

is that the listeners can join the broadcast at any 
time or they can even remove themselves. And the 
broadcast class itself doesn't know anything about 
the listeners, any object can register that 
implements the right interface. 


Time—Consuming 


Incomplete Confusing 
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Suecinet ry 


Precise cae 


Complete _ 73 


your vocabulary 


Observer 


Top five ways to share your vocabulary 


1 In design meetings: When you meet with your team to discuss 
a software design, use design patterns to help stay “in the design” 
longer. Discussing designs from the perspective of Design Patterns 
and OO principles keeps your team from getting bogged down in 
implementation details and prevent many misunderstandings. 


2 With other developers: Use patterns in your discussions with 
other developers. This helps other developers learn about new 
patterns and builds a community. The best part about sharing what 
you've learned is that great feeling when someone else “gets it!” 


3 In architecture documentation: When you write 
architectural documentation, using patterns will reduce the amount 
of documentation you need to write and gives the reader a clearer 
picture of the design. 


4 In code comments and naming conventions: When 
you're writing code, clearly identify the patterns you're using in 
comments. Also, choose class and methods names that reveal any 
patterns underneath. Other developers who have to read your 
code will thank you for allowing them to quickly understand your 
implementation. 


5 To groups of interested developers: Share your knowledge. 
Many developers have heard about patterns but don’t have a good 
understanding of what they are. Volunteer to give a brown-bag lunch 
on patterns or a talk at your local user group. 


Cruisin’ Objectville with 
the Gang of Four 


You won’t find the Jets or Sharks hanging around Objectville, but 
you will find the Gang of Four. As you’ve probably noticed, you 
can’t get far in the World of Patterns without running into them. 
So, who is this mysterious gang? 


Put simply, “the GoF,” which includes Erich Gamma, Richard 
Helm, Ralph Johnson and John Vlissides, is the group of guys who 


put together the first patterns catalog and in the process, started an 


entire movement in the software field! 


How did they get that name? No one knows for sure; it’s Just a 
name that stuck. But think about it: if you’re going to have a 
“gang element” running around Objectville, could you think of a 


nicer bunch of guys? In fact, they’ve even agreed to pay us a visit... 


Today 
there are more 
patterns than in the 
GoF book; learn about 
them as well. 


Shoot for practical 
extensibility. Don't 
provide hypothetical 

generality; be extensible 

in ways that matter. 


anni 
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The GoF launched the software 
patterns movement, but many others 
have made significant contributions, 
including, Ward Cunningham, Kent 
Beck, Jim Coplien, Grady Booth, Bruce 
Anderson, Richard Gabriel, Doug, Lea, 
Peter Coad, and Doug Schmidt, to 
name just a few. 


Go for simplicity 
and don't become over-excited. 
If you can come up with a 
simpler solution without using a 
pattern, then go for it. 


~~ Ralph 


Johnson 


Patterns are 
tools not rules - they 
need to be tweaked and 
adapted to 
your problem. 


Erich Gamma 
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patterns resources 


Your journey has just begun... 


Now that you’re on top of Design Patterns and ready to dig deeper, we’ve got three definitive 


texts that you need to add to your bookshelf... 


Design Patterns 


Elements of Reusable 


Pot 


The definitive Patterns texts 


Patterns didn’t start with the GoF; they started with 
Christopher Alexander, a Professor of Architecture 
at Berkeley — that’s right, Alexander is an architect, 
not a computer scientist. Alexander invented 
patterns for building living architectures (like 
houses, towns and cities). 


The next time you’re in the mood for some deep, 
engaging reading, pick up The Timeless Way of 
Building and A Pattern Language. You'll see the true 
beginnings of Design Patterns and recognize 

the direct analogies between creating “living 
architecture” and flexible, extensible software. 


So grab a cup of Starbuzz Coffee, sit back, and 
enjoy... 
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The definitive Design Patterns text 


This is the book that kicked off the entire field of Design 
Patterns when it was released in 1995. You'll find all the 
fundamental patterns here. In fact, this book is the basis for 
the set of patterns we used in Head First Design Patterns. 


You won't find this book to be the last word on Design 
Patterns — the field has grown substantially since its 
publication — but it is the first and most definitive. 


Picking up a copy of Design Patterns is a great way to start 
exploring patterns after Head First. 


Patterns are » 


The authors of Design re “Gano, of Four 


affectionately Known as 
or Gor Lor short: 


Christopher Alexander invented 
patterns, which inspired appl ing similar 
solutions to software. “ 
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Other Design Pattern resources 


You’re going to find there is a vibrant, friendly community of patterns 
users and writers out there and they’re glad to have you join them. 
Here’s a few resources to get you started... 


The Portland Patterns Repository, run by 
Ward Cunningham, is a WIKI devoted to all 
things related to patterns. Anyone can participate. 


SHE 
I Portland Pattern Repository 


5 adia dca paki aml : You'll find threads of discussion on every topic 
coe you can think of related to patterns and OO 

© Pattern Language Catalog 

Mees cmt na rp eta ie et systems. 


‘© People, Projects & Patterns 


http://c2.com/cgi/wiki?WelcomeVisitors 


‘The Hillside Group's Pattems Home Page lists other p. 
books, conferences, 


New survey results are in, This form tallies survey res 
to see what people like about the repository. Then add 


re ee = 2 The Hillside Group fosters common 

—— programming and design practices and provides 
a central resource for patterns work. The site 
includes information on many patterns-related 
resources such as articles, books, mailing lists and 
tools. 


http://hillside.net/ 


Make a splash in Vancouver... 


And if you'd like to get some face-to-face time with 
the patterns community, be sure to check out the 
many patterns related conferences and workshops. 
The Hillside site maintains a complete list. At 

the least you’ll want to check out OOPSLA, the 
ACM Conference on Object-Oriented Systems, 
Languages and Applications. 


19th Annual ACM Conference on Object-Oriented 
Programming, Uangvoges, 
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The Patterns Zoo 


As you've just seen, patterns didn’t start with software; they started 
with the architecture of buildings and towns. In fact, the patterns 
concept can be applied in many different domains. ‘Take a walk 
around the Patterns Zoo to see a few... 


Architectural Patterns are 
used to create the living, 


vibrant architecture of Habitat: found in buildings you 
buildings, towns, and cities. like to live in, look at and visit. 
This is where patterns got 
their start. 
Habitat: seen hanging around Application Patterns are 
3_tier architectures, Client— 


patterns for creating 
server systems and the web- system level architecture. 
Many multi-tier 
architectures fall into this 
category. 


Field note: MVC has been 
known to Pass for an 
application pattern. 


Domain-Specific Patterns _ Help find a habitat 
are patterns that concern EE 
problems in specific domains, 
like concurrent systems or 
real-time systems. 
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Business Process Patterns 
describe the interaction 
between businesses, customers 
and data, and can be applied 

to problems such as how 

to effectively make and 
communicate decisions. 


Help find a habitat 
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Seen hanging around Corporate 
boardrooms and Project 
management meetings. 


7 —~S Organizational Patterns 


describe the structures 


Development team 


and practices of human 


Customer support team 


organizations. Most 
efforts to date have 


focused on organizations 


that produce and/or 


User Interface 
Design Patterns 
address the 
problems of how to 
design interactive 
software programs. 


Habitat: seen in the vieinity 
of video game designers, Gul 
builders, and producers. 


Field notes: please add your observations of pattern domains here: 


support software. 
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Annihilating evil with Anti-Patterns 


The Universe just wouldn’t be complete if we had patterns and no 


anti-patterns, now would it? 


If a Design Pattern gives you a general solution to a recurring 
problem in a particular context, then what does an anti-pattern 
give you? 


An Anti-Pattern tells you how to go from a problem 


to a BAD solution. 


You're probably asking yourself, “Why on earth would anyone 
waste their time documenting bad solutions?” 


Think about it like this: if there is a recurring bad solution to a 
common problem, then by documenting it we can prevent other 
developers from making the same mistake. After all, avoiding bad 
solutions can be just as valuable as finding good ones! 


Let’s look at the elements of an anti-pattern: 


An anti-pattern tells you why a bad solution is 
attractive. Let’s face it, no one would choose a bad solution if 
there wasn’t something about it that seemed attractive up front. 
One of the biggest jobs of the anti-pattern is to alert you to the 
seductive aspect of the solution. 


An anti-pattern tells you why that solution in the long 
term is bad. In order to understand why it’s an anti-pattern, 
you've got to understand how it’s going to have a negative effect 
down the road. The anti-pattern describes where you'll get into 
trouble using the solution. 


An anti-pattern suggests other patterns that are 
applicable which may provide good solutions. ‘To be 
truly helpful an anti-pattern needs to point you in the right 
direction; it should suggest other possibilities that may lead to 
good solutions. 


Let’s have a look at an anti-pattern. 


An anti-pattern always 
looks like a good solution, 
but then turns out to be 
a had solution when it is 


applied. 


By documenting anti- 
patterns we help 
others to recognize had 
solutions hefore they 
implement them. 


Like patterns, there 
are many types 

of anti-patterns 
including development, 
00, organizational, 
and domain specific 
anti-patterns. 
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Here’s an example of a software development anti-pattern. i) 


be Anti-Pottenn - 


Name: Golden Hammer 


Just like a Design Pattern, 


an anti-pattern has a name 
so we ¢an éreate a shared 
vocabulary. 


Problem: You need to choose technologies for 
your development and you believe that exactly one 
technology must dominate the architecture. 


Context: You need to develop some new system 
or piece of software that doesn’t fit well with the 
technology that the development team is familiar with. 


The problem and context, 
just like a Design Pattern 


description. Parces- 
* The development team is committed to the 
technology they know. 

* The development team is not familiar with 

Tells you why other technologies. 
ion is + Unfamiliar technologies are seen as risky. 

the solu Unfamiliar technologi isk 
attractive. + Itis easy to plan and estimate for 


development using the familiar technology. 


Supposed Solution: Use the familiar technology 
anyway. The technology is applied obsessively to 
many problems, including places where it is clearly 


The bad, yet attractive solution inappropriate. 


How to get to a a 


Refactored Solution: Expanding the knowledge of 
developers through education, training, and book 
study groups that expose developers to new solutions. 


Examples: 


good solution. 
Web companies keep using and maintaining their 
internal homegrown caching systems when open 
source alternatives are in use. 


Example of where this anti-pattern 


has been observed. 


om the Portland Pattern 


le tp:// t2.com/ 
story's W X¥| at hete 
cual i ae many anti patterns and 


discussions: 
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Tools for your Design Toolbox 


) You’ve reached that point where you’ve outgrown us. 
Now’s the time to go out in the world and explore 
patterns on your own... 


0 Basies 


Rostraction 
Encapsulavion 
Palymorpris™ 
Inheritance 


OO Principles 


what varies 


Eneapsulate oe 
apheritance- 
Favor composition over inh 
aN! 


Program to anterrkacess not 
iyaplementarions 


Ons. 
Jy coupled design 
Se wea bat interact The time has Come 
between ° 


for You to go out and 


for extension 


en 
ould bbe OREN . nS 
Classes $ ieee fication. discover more patte n 
but close on Your own. There ave 
es Do not . “ft. 
Derend on abstraction” many domain-specific 
er’ 


ontwete classes 


devend on patterns we hee even 
friends: mentioned and there are 
tp your 
Only talk 1 wees also some foundational 
Dont tall vs) We yeany ones we didn't cover. 


e reason to 


should have only on You ve also got patterns 


of Your own to ereate. 
OO Patterns = 
Si r= 


| 
ere. 

ANN Proxy - Prot Your Patterns i 
in plateholder for | ae 


) class 
change: 


Check out the 
Appendix, we'll 
give You a heads 


\\\ \ putes up on Some more 
Ve tontro! ee foundational 
Come in patterns you'll 
probably want to 
N ces have a look at. 
more 
 — solves 3 © 
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BULLET rout 


= Always use the simplest 
= Study Design Pattern catalogs 


= Pattern classifications (or 


= Let Design Patterns emerge in 
your designs, don’t force them 
in just for the sake of using a 
pattern. 


= Design Patterns aren't set in 
stone; adapt and tweak them to 
meet your needs. 


solution that meets your needs, 
even if it doesn’t include a 
pattern. 


to familiarize yourself with 
patterns and the relationships 
among them. 


categories) provide groupings 
for patterns. When they help, 
use them. 


You need to be committed to 
be a patterns writer: it takes 
time and patience, and you 
have to be willing to do lots of 
refinement. 


Remember, most patterns you 
encounter will be adaptations 
of existing patterns, not new 
patterns. 


Build your team’s shared 
vocabulary. This is one of the 
most powerful benefits of using 
patterns. 


Like any community, the 
patterns community has its 
own lingo. Don’t let that hold 
you back. Having read this 
book, you now know most of it. 


better living with patterns 


Leaving Objectville... 


Boy, it’s been great having you in Objectville. 


We're going to miss you, for sure. But don’t worry — before you know it, the 
next Head First book will be out and you can visit again. What's the next book, 
you ask? Hmmm, good question! Why don’t you help us decide? Send email 
to booksuggestions@wickedlysmart.com. 
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who does what? solution 


Match each pattern with its description: 


Pattern 


Decorator 


Proxy 
Factory Meth 
Adapter 
Observer 


Template Metho 


We 


Composite MJ 


Singleton S 


Abstract Facto 


Command———_— 


Ce Exereise solutions 
WHE DOES WHAT? 


Description 


Wraps an object and provides a different 
interkace to it. 


Subclassesdecide howtoimplementstepsin 
an algorithm. 


Subclasses decide which concrete classesto 
create. 


Ensures one and only object is created. 


Encapsulatesinterchangeablebehaviorsand 
uses delegation to decide which one to use. 


Clients treat collections of objects and 
individual objects uniformly. 


Eneapsulatesstate-basedbehaviorsanduses 
delegation to switch between behaviors. 


Provides a way te traverse a collection of 
objects withoutex posing itsimplementation. 
Simplifies the interface of a set of classes. 
Wraps an object to provide new behavior. 


Allows a clientte create families of objects 
without specifying their concrete classes. 


Allows objects to be notified when state 
changes. 


Wraps an object to control access to it. 
Encapsulates a request as an object. 


14 Appendix 
Appendix: Leftover Patterns 


Not everyone can be the most popular. A lot has changed in 

the last 10 years. Since Design Patterns: Elements of Reusable Object-Oriented 
Software first came out, developers have applied these patterns thousands 

of times. The patterns we summarize in this appendix are full-fledged, card- 
carrying, official GoF patterns, but aren’t used as often as the patterns we’ve 
explored so far. But these patterns are awesome in their own right, and if your 
situation calls for them, you should apply them with your head held high. Our 
goal in this appendix is to give you a high level idea of what these patterns are all 


about. 
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bridge pattern 


Bridge 
Use the Bridge Pattern to vary not only your 
implementations, but also your abstractions. 


is i abstraction. It tould be 
ee eae an abstract Class. 


Imagine you’re going to revolutionize “extreme 
lounging.” You’re writing the code for a new 
ergonomic and user-friendly remote control for 
TVs. You already know that you’ve got to use 
good OO techniques because while the remote is 


based on the same abstraction, there will be lots of 
implementations — one for each model of TV. Every rem ote has the 


RemoteControl 


on() 
same abstraction ——» | off) 


setChannel() 


// more methods 


RCAControl SonyControl 
Lots of ont) oni) 
implementations, offt) oft 
one Loy each Ty, setChannel() a setChannel() 
/I more methods’. // more methods 


{ 
Your dilemma } 


tuneChannel(channel); 


You know that the remote’s user interface won’t be right the 
first time. In fact, you expect that the product will be refined 
many times as usability data is collected on the remote 
control. 


Usina this design we Can vary 
aaly the TV implementation, not 


the TVs are going to change. You’ve already abstracted the user the user interface. 
interface so that you can vary the zmplementation over the many 


So your dilemma is that the remotes are going to change and 


TVs your customers will own. But you are also going to need 
to vary the abstraction because it 1s going to change over time as 
the remote is improved based on the user feedback. 


So how are you going to create an OO design that allows you 
to vary the implementation and the abstraction? 
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Why use the Bridge Pattern? 


The Bridge Pattern allows you to vary the implementation and 


the abstraction by placing the two in separate class hierarchies. 


Blostrattion 


class hierarchy: \ 


RemoteControl 


implementor 


on() 
off() 


// more methods 


ConcreteRemote 


currentStation 


on() 

off() 

setStation() 
nextChannel() -*"” : 
previousChannel() 


// more methods 


setChannel() ....-----7- "eo 


The relationship between 


<— the two is referred to as 


the “bridge.’ 


Has-A 


U 


leftover patterns 


Implementation Class hierarchy. 


implementor.tuneChannel(channel); 


All methods in the abstraction 


are implemented in terms 


the impl ementation. 


on() 
off) 
tuneChannel() 


// more methods 


*’! setChannel(currentStation + 1); | 


a Conerete subclasses are implemented in terms of the 


RCA Sony 
on() on() 
off() off() 
tuneChannel() tuneChannel() 
// more methods // more methods 


abstraction, not the implementation. 


Now you have two hierarchies, one for the remotes and a separate one for platform 


specific T'V implementations. The bridge allows you to vary either side of the two 


hierarchies independently. 


Bridge Benefits 
permanently to an interface. 
independently. 


affect the client. 


= Decouples an implementation so that it is not bound 
= Abstraction and implementation can be extended 


= Changes to the concrete abstraction classes don’t 


‘Bridge Uses and Drawbacks 
= Useful in graphics and windowing systems that need 


to run over multiple platforms. 


= Useful any time you need to vary an interface and an 


implementation in different ways. 


= Increases complexity. 
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builder pattern 


Builder 


Use the Builder Pattern to encapsulate the construction of 
a product and allow it to be constructed in steps. 


A scenario 

You've just been asked to build a vacation planner for Patternsland, a new theme 

park just outside of Objectville. Park guests can choose a hotel and various types of 
admission tickets, make restaurant reservations, and even book special events. To create 


a vacation planner, you need to be able to create structures like this: 
Each vacation is planned 


a over some number of days. 


Vacario% 


A\\ = i 
O iXo DOOTe, 


2 FS 
Hore “ark Tie” ad Oinina GT Hote deci 


(97 oO 
y .: a 
Dinne* &rns 0% Dinne™ We Dee 


You need a flexible design 


Each guest’s planner can vary in the number of days and types of activities it includes. 
For instance, a local resident might not need a hotel, but wants to make dinner and 
special event reservations. Another guest might be flying into Objectville and needs a 
hotel, dinner reservations, and admission tickets. 


So, you need a flexible data structure that can represent guest planners and all their 
variations; you also need to follow a sequence of potentially complex steps to create the 
planner. How can you provide a way to create the complex structure without mixing it 
with the steps for creating it? 
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Why use the Builder Pattern? 


Remember Iterator? We encapsulated the iteration into a separate 

object and hid the internal representation of the collection from the 

client. It’s the same idea here: we encapsulate the creation of the 

trip planner in an object (let’s call it a builder), and have our client 

ask the builder to construct the trip planner structure for it. 
The elient uses an 
abstract interface to 


( build the planner. 


oe builder 
The Client | Client AbstractBuilder 
diveets the constructPlanner() - buildDay() 
builder to : addHotel() 

, addReservation() 
construct the : addSpecialEvent() 
planner. : addTickets() 

: getVacationPlanner() 


ilder 
builder.buildDay(date); The conerete bui i 
builder.addHotel(date, “Grand Facadian’”); ereates veal produt 
builder.addTickets(“Patterns on Ice”); and stores them in 


ite 
// plan rest of vacation VacationBuilder - se Compost 
; wucture- 
Planner yourPlanner = vacation 
builder.getVacationPlanner(); buildDay() 
addHotel() 
addReservation() 
addSpecialEvent() 
addTickets() 
ne Client dive tts the builder to treate getVacationPlanner() 
i planner in 3 number of steps ig 
then talls the getVacation?lannty biett: 
ethod to retrieve Lhe complete ob) 
m 
-—Builder Benefits ‘Builder Uses and Drawbacks 
= “Eneapetlates fie Way-a Comploxabjoclis = — Often used for building composite structures. 
constructed. 


= Constructing objects requires more domain 


* Allows objects to be constructed in a multistep and knowledge of the client than when using a Factory. 


varying process (as opposed to one step factories). 
= Hides the internal representation of the product from 
the client. 
= Product implementations can be swapped in and out 
because the client only sees an abstract interface. 
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chain of responsibility 


Chain of Responsibility 


Use the Chain of Responsibility Pattern when you want to 
give more than one object a chance to handle a request. 


A scenario 

Mighty Gumball has been getting more email 
than they can handle since the release of the 
Java-powered Gumball Machine. From their 
own analysis they get four kinds of email: fan 
mail from customers that love the new | in 10 
game, complaints from parents whose kids 

are addicted to the game and requests to put 
machines in new locations. They also get a fair 
amount of spam. 


All fan mail should go straight to the CEO, all 
complaints should go to the legal department 
and all requests for new machines should go to 


business development. Spam should be deleted. 


Your task 
Mighty Gumball has already written some AI 


detectors that can tell if an email is spam, fan 
mail, a complaint, or a request, but they need 
you to create a design that can use the detectors 
to handle incoming email. 


616 


You've 
got to help us 
deal with the flood 
of email we're getting 
since the release of 
the Java Gumball 
Machine. 
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How to use the Chain of Responsibility Pattern 


With the Chain of Responsibility Pattern, you create a chain of objects 
to examine requests. Each object in turn examines a request and either 
handles it, or passes it on to the next object in the chain. 


Handler 


successor 


Each object in the chain 

gets as a handler and has 

a successor object: |x i 

tan handle the request, 

it does; otherwise, it 

forwards the request | | 
eee | SpamHandler | FanHandler 


handleRequest() 


| ComplaintHandler | NewLocHandler 


handleRequest() 


handleRequest() 


handleRequest() 


handleRequest() 


As email is received, it is passed to the first handler: the 
SpamHandler. If the SpamHandler can’t handle the request, 


Email is not handled if it 
it is passed on to the FanHandler. And so on... Lalls off the end ab tie 
to chain — although, You Can always 
fog eel implement a e3tch-all handler. 
the first handler. 


Spam 


Fan NewLoc 


Handler 


Handler 


Handler 


-— Chain of Responsibility Benefits 


Chain of Responsibility Uses and Drawbacks. 


Decouples the sender of the request and its 
receivers. 


Commonly used in windows systems to handle 

events like mouse clicks and keyboard events. 
Simplifies your object because it doesn’t have to Execution of the request isn’t guaranteed; it may fall 
know the chain’s structure and keep direct references off the end of the chain if no object handles it (this can 
to its members. be an advantage or a disadvantage). 


Allows you to add or remove responsibilities Can be hard to observe and debug at runtime. 


dynamically by changing the members or order of the 
chain. 
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flyweight pattern 


Flyweight 
Use the Flyweight Pattern when one instance of a class 
can be used to provide many “virtual instances.” 


A scenario 

You want to add trees as objects in your hot new landscape design application. In 
your application, trees don’t really do very much; they have an X-Y location, and they 
can draw themselves dynamically, depending on how old they are. The thing 1s, a user 


might want to have lots and lots of trees in one of their home landscape designs. It 
might look something like this: 


Each Tree instanee 
maintains its own stat 
C: 
| Tree 
xCoord 
yCoord 
age 
display() { 


// use X-Y coords 
// & complex age 
// related calcs 


} 


Your big client’s dilemma 


You've just landed your “reference account.” ‘That key client 
you've been pitching for months. ‘They’re going to buy 1,000 
seats of your application, and they’re using your software 

to do the landscape design for huge planned communities. 
After using your software for a week, your client is 
complaining that when they create large groves of trees, the 
app starts getting sluggish... 


618 appendix 


Why use the Flyweight Pattern? 


What if, instead of having thousands of Tree objects, you 
could redesign your system so that you’ve got only one 
instance of ‘Tree, and a client object that maintains the state 
of ALL your trees? That’s the Flyweight! 


All the state, for ALL 
of your virtual Tree 
objects, is stored in 


this 2D-arvay: 
\ TreeManager 
treeArray 


displayTrees() { 
/! for all trees { 
// get array row 
display(x, y, age); 
} 


-— Flyweight Benefits 


leftover patterns 


One, Single, 


ree object. *tate-tree 


display(x, y, age) { 
// use X-Y coords 
// & complex age 
// related calcs 


} 


= Reduces the number of object instances at runtime, 
saving memory. 

= Centralizes state for many “virtual” objects into a 
single location. 


Flyweight Uses and Drawbacks 


The Flyweight is used when a class has many 
instances, and they can all be controlled identically. 
A drawback of the Flyweight pattern is that once 
you've implemented it, single, logical instances of the 
class will not be able to behave independently from 
the other instances. 
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interpreter patiern 


Interpreter 


Use the Interpreter Pattern to build an 
interpreter for a language. 


A scenario 

Remember the Duck Pond Simulator? You have a hunch it 
would also make a great educational tool for children to learn 
programming. Using the simulator, each child gets to control one 
duck with a simple language. Here’s an example of the language: 


a 


right; Fly all day... 
while (daylight) fly; 4~ y : 
quack; 


Turn the duck vight 


<™ «and then quack. 


Now, remembering how to create grammars from one of your old 
introductory programming classes, you write out the grammar: «on Consistind, 


a 
£ com 
ces o : " 
/ e ie (“while ctatements 
: A senuence isa set of 


expressions separated 


expression ::= <command> | <sequence> | <repetition> L— bbe <onitbolons 
sequence ::= <expression> ‘;’ <expression> 7 


command ::= right | quack | fly 
repetition ::= while ‘(‘ <variable> ’)’<expression> We have three 


variable ::= [A-Z,a-z]+ Commands: right, 


K ere 
A while statement is just 


9 Conditional variable and 
an €XPression. 


Now what? 


You've got a grammar; now all you need is a way to represent and 
interpret sentences in the grammar so that the students can see the 
effects of their programming on the simulated ducks. 
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How to implement an interpreter 


When you need to implement a simple language, the 


Interpreter Pattern defines a class-based representation for its 


grammar along with an interpreter to interpret its sentences. 


To represent the language, you use a class to represent each 


rule in the language. Here’s the duck language translated 


into classes. Notice the direct mapping to the grammar. 


Expression 


interpret(context) 


Repetition 


over patterns 


Sequence 


variable 
expression 


expression1 
expression2 


interpret(context) 


interpret(context) 


Variable 


QuackCommand 


RightCommand 


FlyCommand 


interpret(context) 


To interpret the language, call the interpret() method on each 
expression type. This method is passed a context — which 
contains the input stream of the program we’re parsing — and 
matches the input and evaluates it. 


-—interpreter Benefits 


interpret(context) 


interpret(context) 


Representing each grammar rule in a class makes 
the language easy to implement. 


Because the grammar is represented by classes, you 
can easily change or extend the language. 


By adding additional methods to the class structure, 
you can add new behaviors beyond interpretation, 
like pretty printing and more sophisticated program 
validation. 


Interpreter Uses and Drawbacks 


Use interpreter when you need to implement a 


simple language. 


Appropriate when you have a simple grammar and 
simplicity is more important than efficiency. 

Used for scripting and programming languages. 
This pattern can become cumbersome when the 
number of grammar rules is large. In these cases a 
parser/compiler generator may be more appropriate. 


you 


interpret(context) 
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mediator pattern 


Mediator 


Use the Mediator Pattern to centralize complex 
communications and control between related objects. 


A scenario 

Bob has a Java-enabled auto-house, thanks to the good folks at HouseOfTheFuture. 
All of his appliances are designed to make his life easier. When Bob stops hitting the 
snooze button, his alarm clock tells the coffee maker to start brewing. Even though 
life is good for Bob, he and other clients are always asking for lots of new features: 
No coffee on the weekends... ‘Turn off the sprinkler 15 minutes before a shower is 
scheduled... Set the alarm early on trash days... 


CoffeePot 
Alarm 
onEvent() { 
onEvent() { checkCalendar() 
checkCalendar() checkAlarm() 
checkSprinkler() // do more stuff 
startCoffee() } 
// do more stuff 
} 
| Calendar I 
Sprinkler 
onEvent() { Event 
cheese Day Ones!) ee eas 
Hos panken) checkShower() 
doCoffee 
parraairY checkTemp() 
// do more stuff oe 
Oo more stu 
} 


HouseOfTheFuture’s dilemma 


It’s getting really hard to keep track of which rules reside in which objects, and how 
the various objects should relate to each other. 
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Mediator in action... 


With a Mediator added to the system, all 
of the appliance objects can be greatly 
simplified: 


They tell the Mediator when their state 


changes. 


They respond to requests from the 


Mediator. 


Before adding the Mediator, all of the 
appliance objects needed to know about each 
other... they were all tightly coupled. With the 
Mediator in place, the appliance objects are 
all completely decoupled from each other. 


The Mediator contains all of the control 
logic for the entire system. When an existing 
appliance needs a new rule, or a new 
appliance is added to the system, you'll know 
that all of the necessary logic will be added to 
the Mediator. 


-— Mediator Benefits 


CoffeePo 


y, 
\ 


Increases the reusability of the objects supported by 
the Mediator by decoupling them from the system. 
Simplifies maintenance of the system by centralizing 
control logic. 


Simplifies and reduces the variety of messages sent 
between objects in the system. 


overly complex. 


5 


= The Mediator is commonly used to coordinate related 
GUI components. 

= Adrawback of the Mediator pattern is that without 
proper design, the Mediator object itself can become 


leftover patterns 


It's sucha 
relief, not having to 
figure out that Alarm 
clock's picky rules! 


Mediator 


if(alarmEvent){ 
checkCalendar() 
checkShower() 
checkTemp() 


if(weekend) { 
checkWeather() 
// do more stuff 


if(trashDay) { 
resetAlarm() 
// do more stuff 


} 


Mediator Uses and Drawbacks 


memento pattern 


Memento 


Use the Memento Pattern when you need 
to be able to return an object to one of its 
previous states; for instance, if your user 
requests an “undo.” 


A scenario 


Your interactive role playing game is hugely successful, 
and has created a legion of addicts, all trying to get 

to the fabled “level 13”. As users progress to more 
challenging game levels, the odds of encountering 

a game-ending situation increase. Fans who have 

spent days progressing to an advanced level are 
understandably miffed when their character gets snuffed, 
and they have to start all over. The cry goes out for a 
“save progress” command, so that players can store their 
game progress and at least recover most of their efforts 
when their character is unfairly extinguished. The 
“save progress” function needs to be designed to return 
a resurrected player to the last level she completed 
successfully. 


Just be careful how you go about 
saving the game state. It's pretty 
complicated, and I don't want anyone 
else with access to it mucking it up and 
breaking my code. 
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The Memento at work 


The Memento has two goals: 


= Saving the important state of a system’s key object. 


=" Maintaining the key object’s encapsulation. 


Keeping the single responsibility principle in mind, it’s also 
a good idea to keep the state that you’re saving separate 

from the key object. This separate object that holds the GameMemento 
state is known as the Memento object. 


savedGameState 


Client MasterGameObject 


// when new level is reached gameState 
Object saved = 
je (Object) mgo.getCurrentState(); Object getCurrentState() { 
// gather state 

// when a restore is required return(gameState); 
While this isn’t a terribly mgo.restoreState(saved); } 
fancy inplenentayon restoreState(Object savedState) { 
notice that the Clien // restore state 


has no access to the 


} 
M emento s data. 


// do other game stuff 


Memento Benefits Memento Uses and Drawbacks 


helps to maintain iil = Adrawback to using Memento is that saving and 
= Keeps the key object's data encapsulated. restoring state can be time consuming. 


" Provides easy-to-implement recovery capability. = In Java systems, consider using Serialization to save 


a system's state. 
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prototype pattern 


Prototype 


Use the Prototype Pattern when creating an 


instance of a given class is either expensive or 
complicated. 


A scenario 


Your interactive role playing game has an insatiable appetite for monsters. As your 
heros make their journey through a dynamically created landscape, they encounter 
an endless chain of foes that must be subdued. You’d like the monster’s characteristics 
to evolve with the changing landscape. It doesn’t make a lot of sense for bird-like 


monsters to follow your characters into underseas realms. Finally, you’d like to allow 
advanced players to create their own custom monsters. 


Yikes! Just the act 
of creating all of these different 
kinds of monster instances is getting 
tricky... Putting all sorts of state detail in the 
constructors doesn't seem to be very cohesive. It 
would be great if there was a single place where 
all of the instantiation details could be 
encapsulated... 


It would be a lot cleaner if we 
could decouple the code that handles 
the details of creating the monsters 
from the code that actually needs to 

create the instances on the fly. 


Prototype to the rescue 


The Prototype Pattern allows you to make new instances by 
copying existing instances. (In Java this typically means using 


leftover patterns 


the clone() method, or de-serialization when you need deep 
copies.) A key aspect of this pattern is that the client code can 
make new instances without knowing which specific class is 
being instantiated. 


<<interface>> 
Monster 


we 


WellKnownMonster 


MonsterMaker 


makeRandomMonster() { 
Monster m = 
MonsterRegistry.getMonster(); 


MonsterRegistry 


Monster getMonster() { 
// find the correct monster 
return correctMonster.clone(); 


} 


-— Prototype Benefits 


DynamicPlayerGeneratedMonster 


The client needs a new el 
appropriate to the curren’ 

sae (The client won + know 
what kind of monster he gets.) 


—_ The registry finds 


the a i 
monster, makes a Clone oie soa : 
returns the Clone. ” 


Prototype Uses and Drawbacks 


= Hides the complexities of making new instances from 
the client. 


= Provides the option for the client to generate objects 
whose type is not known. 

= In some circumstances, copying an object can be 
more efficient than creating a new object. 


Prototype should be considered when a system must 
create new objects of many types in a complex class 
hierarchy. 

A drawback to using the Prototype is that making a 
copy of an object can sometimes be complicated. 
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visitor pattern 


Visitor 
Use the Visitor Pattern when you want to 


add capabilities to a composite of objects 
and encapsulation is not important. 


A scenario 


Customers who frequent the Objectville Diner and Objectville 
Pancake House have recently become more health conscious. They 
are asking for nutritional information before ordering their meals. 
Because both establishments are so willing to create special orders, 
some customers are even asking for nutritional information on a 
per ingredient basis. 


Lou’s proposed solution: // new methods 


getCalores 
ot nhl en 


getProtein a 


getCarbs ——________ 


// new methods 


getHealthRating 
getCalories a 
getProtein _ 


getCarbs ——_______ 


Mel's concerns... 


“Boy, it seems like we’re opening Pandora’s box. Who knows what 
new method we’re going to have to add next, and every time we 
add a new method we have to do it in two places. Plus, what if 
we want to enhance the base application with, say, a recipes class? 
Then we’ll have to make these changes in three different places...” 
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es 


The Visitor drops by 


The Visitor works hand in hand with a Traverser. The Traverser 
knows how to navigate to all of the objects in a Composite. The 
Traverser guides the Visitor through the Composite so that the Visitor 
can collect state as it goes. Once state has been gathered, the Client 
can have the Visitor perform various operations on the state. When 
new functionality is required, only the Visitor must be enhanced. 


The Visitor needs to be able to call 


d this is 
; getStatel) atiross Classes, an 
The Client asks d new methods for 
the Visitor to get 
information from the 
Composite structure... 
New methods can be 
added to the Visitor 
without affecting the 


Composite. 


where you can ad 
the client to use- 


J gerstatel) +> 


etait | getState() 
6 OSie, = > 
ete 


The Traverser knows how to 
guide the Visitor through 
the Composite structure. 


-— Visitor Benefits Visitor Drawbacks 


leftover patterns 


All these composite 
classes have to do is add 
a getStatel) method 
(and not worry about 


exposing, themselves). 


J 


= Allows you to add operations to a Composite . 


structure without changing the structure itself. when the Visitor is used. 
= Adding new operations is relatively easy. = Because the traversal function is involved, changes to 
= The code for operations performed by the Visitor is the Composite structure are more difficult. 
centralized. 


The Composite classes’ encapsulation is broken 
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And now, a final word from the Head First Institute... 


Our world class researchers are working day and night in a mad race to 

uncover the mysteries of Life, the Universe and Everything—before it's too late. 
Never before has a research team with such noble and daunting goals been 
assembled. Currently, we are focusing our collective energy and brain power on 
creating the ultimate learning machine. Once perfected, you and others will join 


us in our quest! 


You're fortunate to be holding one of our first protoypes in your hands. But only 
through constant refinement can our goal be achieved. We ask you, a pioneer 
user of the technology, to send us periodic fleld reports of your progress, at 


fleldreports@wickedlysmart.com 


And next time you're in Objectville, 
drop by and take one of our behind 
the scenes laboratory tours. 


